[Tinyos-devel] Request for comments: TEP107

[David Moss]

There is still time to provide your comments on TEP107 - TinyOS 2.x Boot
Sequence  

Neil brought up some good points about how to assess whether or not the boot
process is successful or even working, especially for new platforms.
Restating Phil's argument, the flexibility of TinyOS allows extra debugging
functionality to be added in as needed, without affecting users who don't
require extra functionality.  The TEP exists to specify the minimum boot
functionality, but it might be useful for someone to create a new version of
the boot component that provides debugging functionality.  Debugging
functionality could also be added in seperately on a per-project, as-needed
basis.

If you have any input, we would like to hear it now before TEP107 moves
toward finalization.

http://www.tinyos.net/tinyos-2.x/doc/html/tep107.html

-David Moss




-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Tuesday, October 31, 2006 8:49 AM
To: Neil Hancock
Cc: 'David Moss'; tinyos-devel at Millennium.Berkeley.EDU
Subject: Re: [Tinyos-devel] Request for comments: TEP107


On Oct 29, 2006, at 9:20 PM, Neil Hancock wrote:

>
> [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:]
>
>

That makes sense. But I think it's something which the core itself  
doesn't need to specify. One could very easily introduce a component  
above Boot which does all of what you're mentioning (e.g., add  
another initialization phase). In this case, the simple low-level  
mechanism doesn't preclude greater complexity on top of it; however,  
a more complex mechanism below would preclude simple applications.


> [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:]

I think there's an important point to make here; ultimately, TinyOS  
(even T2) is a component-based OS for which you can easily change  
almost any building block. The TEPs have been written to try to  
specify what a given service MUST or SHOULD or MAY do, in order to  
allow multiple implementations which are compatible. I mean, the boot  
sequence is 8 lines of code; it's not a big deal to have one designed  
for debugging (with lots of error output), one designed for  
production, etc.

No single solution is perfect for all circumstances. We can arguing  
which uses of TinyOS are more important for the one true solution,  
but I think it's more productive to leave the system flexible enough  
that it can be adapted to multiple uses. The goal of the core  
distribution is to be a set of reference implementations of TEPs, not  
the best implementations which fit all needs.

Phil