[Tinyos-devel] TinyOS Alliance WG Feedback
Neil Hancock
neilh10 at biomonitors.com
Fri Jun 23 11:53:54 PDT 2006
Hello TinyOsers and the tinyOsAlliance
There are some great possibilities with TinyOS Alliance, and of course it is
the tidal wave of code that really makes it feel like "surf is up" and lets
have some fun.
Dave, thanks for opening it up for discussion, so I'll try and phrase some
concerns from the wilds of Sonoma county north of Berkeley here in what is
sometimes called Telecom Vineyard.
I know some of the objectives are very blue sky - so I'd like to make some
rather simple and perhaps naïve comments.
There are lots of people having fun working on specific components, so this
an attempt to deepen the proposed organization's framework to support the
TinyOS wireless networking technical focus.
I find myself rather inarticulate on TinyOsXXX, as it seems to range from
the [TinyOs-Help] "help me" to [Tinyos-devel] detailed code fragments.
All very good for the right audience.
Thankyou thankyou for some of the alliance members for putting up minutes
with the gist of the evolving TinyOS 2.0 conversations. It helps to have
some visibility as to what is the direction in TinyOs.
For me, successful embedded event driven code has required "High Level
Designs" descriptions to begin, AND the right
"coding, module testing & verification" environment.
The testing/verification environment turns out to be pretty visible and
require more group think than the coding environment. From past experience,
coding and unit testing are down to individual skills and individual
performers, but the verification paradigm is were a teams skill emerges.
With all the motes based on the different processors Atmega128, msp430, etc
there is quite a unit/module/OS test environment - but the real world
network environment is always a significant more of a challenge and requires
upfront planning to define the needed tradeoffs to make it work.
Its great to see the TEPs coming along, and they are certainly defining some
of the issues.
So my two cents for some technical issues that the alliance might want to
chew on
-1) a published verification suite of code for proving the correctness of
the nesC compiler as it iterates.
-2) a discussion on what sort of TinyOS "Code Promotion" paradigm would be
ideal, with a down to earth process of what is actually likely to be
possible with supported tools
-3) a conversation on the needs of a TinyOs SYSTEM as the modules mature.
-4) Productivity tools
I'm sure 1) is self explanatory, and if there had been an infinite amount of
support available for compiler gurus there probably would be a mature set of
tests there now - if it isn't already there in some capacity. But I wonder
if some sort of a start can’t be made, in a visible place, then it could be
commented on and added to by the group as architectural issues are
re-evolved and inspiration flows.
2) "Code Promotion" - the ability to have modules enhanced and new modules
added, by someone other than the original designer(s) and have it accepted
back into the main development trunk.
(already some discussion on TinyOS_2.x_WG/04.26.2006 contrib->beta->apps?)
It seems to me the code in TinyOs 1.x grew with a few dedicated band of
programmers - all in a mind-meld :) - and they didn't have to communicate
with a larger group.
>From what I've seen with gaggles of software engineers in the software boom
times, having a process to promote code was an essential part of our team
work - how to enable new ideas into a growing code base - without of course
making it a house of cards :) and bringing the system down, which leads on
to
3) The "Systems Approach" - I guess we all know that a system is more than
the components.
What are the requirements of the hibernation paradigm (yes lots of thinking
going on with its own TEP emerging) - the paradigm is pretty tough as it is
dispersed through out the design.
So what are the system level characteristics that TinyOs is going to need
when it is truly ticking as a system. That is what support needs to be built
in now to be able to figure out what is causing anomalous behaviour when the
whole system is ticking (or sometimes getting a bad case of hiccups).
What's needed for the verification paradigm at the system level - a lot of
work goes into constructing the components - so for instance what if a
component misbehaves - something happens intermittently to the TWI bus
because of the hibernation paradigm and it gets stuck - how to have the
instrumentation/primitives in place to track the system level behaviour that
emerges from interacting components.
The introduction of DBG() in tinyos 1.1.15(?) seems to be a recognition of
this, and would be good to be formalized in a TEP, and probably requires a
debug UART dedicated in any new generations of hardware as well. I've
created my own Hw to give me a debug port, for system level intervention.
In general I've found control plane interfaces are needed for almost all
modules - eg LedsC.nc as default for the field wants them off for pwr
saving, but debugging wants them on for visual cues.
What other system approaches are needed - for a working network, if a node
becomes unavailable - how to determine what is going wrong - without
resetting a node, or perhaps every node should be reset every 24 hours as
part of the design, in an attempt to bound possible software rot.
Does a node need valid 'wall time' to make it genuinely part of a user
visible system.
4) Productivity tools (possibly even including documentation) - what is
needed to help new people come up to speed more easily and work more
productive. As it’s aimed at improving "productivity" it may be where some
market orientated approaches can emerge.
Tools mostly aren't that sexy - but absolutely necessary for an environment
were features can roll out reliably.
Personally, if nesC could generate 'C' intermediate to be able to feed into
other tools this would be very big productivity enhancement - and I saw a
reference the other day that maybe this is now possible with nesC 1.2.
I would really like to see a fully symbolic debug environment - supposed to
be there with Atemls Avr Studio 4 - which runs on 'C'. I just haven't had
the time to really try it yet.
So maybe some simplistic ideas, but I throw them out as TinyOS2.0 is just
getting into its hard thinking and project formative phase.
I'd be happy to offer to write a "Component Instrumentation" experimental
TEP, if a couple of people would be prepared to read it and comment it. I've
designated it experimental (TEP 1) as it would require an allocation of a
hardware UART resource not currently accessible in the popular mote designs
that I've seen.
What an amazing synergy of so many people doing so much.
Neil Hancock
> -----Original Message-----
> From: David E. Culler [mailto:culler at eecs.berkeley.edu]
> Sent: Tuesday, May 30, 2006 10:05 AM
> To: tinyos at mail.millennium.berkeley.edu
> Cc: tinyos-alliance at Millennium.Berkeley.EDU; tinyos-devel
> Subject: [Tinyos-devel] TinyOS Alliance WG Feedback
>
> Dear TinyOS Community,
> The TinyOS Alliance Working group has been actively refining the
> structure of the proposed Alliance, which was outlined at the TTX3.
> The following provides a brief overview. Additional detail will be
> available at the Working Group site. We are now starting to solicit
> memberships.
> Before formalizing this organizational structure, we seek feedback from
> the community on the approach. Please do not hesitate to send your
> comments to tinyos-alliance at millennium.berkeley.edu.
>
> Thank you,
>
> David Culler
>
>
>
> TinyOS Open Technology Alliance
>
> Introduction
>
> The TinyOS community has grown to include several thousand developers
> and users in dozens of countries, plus hundreds of companies,
> universities, and government institutions. It has built a broad
> technology base for wireless embedded networks in an open, informal
> collaboration that was largely rooted at the University of California,
> Berkeley. With the growing commericial and technological impact of
> the community and the de facto standards represented by the TinyOS
> technology, we are creating a organizational structure to support the
> worldwide academic and industrial TinyOS community and advance the
> open embedded network ecosystem around TinyOS. This document provides a
> brief overview of the Alliance; greater detail is provided in the Alliance
> Workgroup TEP 120.
>
> Mission
>
> The mission of the TinyOS Alliance is to provide a forum to facilitate:
> * the continued growth of a healthy TinyOS developer and user community
> with support for innovation as well as industry advancement,
> * the development and maintenance of a stable, technically-sound base of
> TinyOS technology and surrounding tools through the creation of
> standard interfaces and protocols, vetted extensions, open reference
> implementations, technical documents, testing and verification suites,
> and educational materials,
> * the contribution of innovative technology from a world-wide research
> community and the maturation and dissemination of these
> contributions, and
> * the promotion of the technology, the community, and the impact of
> networked
> embedded systems.
>
> Participation
>
> The Alliance continues the TinyOS tradition of promoting broad
> membership. It seeks to keep barriers to entry low in all respects:
> legal, financial, and organizational. The Alliance is organized to
> encourage, promote, and credit the contributions of its members. It
> provides an organizational structure that reinforces important,
> broadly adopted design choices to build consensus and establish key de
> facto standard interfaces.
>
> The fundamental membership is individual, as individuals create work
> products,
> serve on working groups and committees, and vote. We have two forms:
>
> * Member: Individual who joins the Alliance and participates at a
> basic level, typically as consumer of technology.
>
> * Contributing Member: Individual who aditionally joins working groups,
> attends meetings, or contributes code or other assets to the
> Alliance. Contributing members are elected to various posts and
> have voting rights.
>
> There is no individual membership fee, but members will be responsible for
> nominal registration fees at Alliance meetings.
>
> Corporations and organizational have institutional membership, which
> reflects
> their degree of effort.
>
> * Institutional Member: Corporation or institutional organization
> that joins the Alliance, agrees to appear on the Alliance
> web site and documents, and pays a nominal administrative fee.
> (Min. Annual $500 for small companies and non-profits, $1000 for
> larger)
>
> * Contributing Institutional Member: Corporation or institutional
> organization that additionally provides financial support, resources,
> facilities, technical contributions, intellectual property,
> marketing support, or other meaningful contributions to the
> Alliance. Such institutions are featured prominently in the Alliance
> and
> have the opportunity to appoint individuals as contributing members.
> (Min. Annual $2000 for small companies and non-profits, $5000 for
> larger)
>
> IP and Licensing
>
> Intellectual property will be addressed in a open manner. Meetings,
> discussions, presentations, and technical documents are
> non-confidential. Membership does not require or provide an explicit
> IP pool, nor does it require conducting a comprehensive IP inventory.
> Members have an on-going responsibility to disclose IP of relvence,
> whether it is their property or not, so that Alliance members can make
> informed decisions and trade-offs. Working groups seek to develop
> approaches, interfaces, and protocols that can reasonably be
> implemented without the use of proprietary technology, although
> companies may well develop their own proprietary versions. Where
> members choose to donate IP, it will be treated along with other forms
> of contribution in establishing member status.
>
> The source licensing policy seeks to promote "rough consensus AND
> running code". In particular, it encourages the creation of quality
> reference implementations of standardized interfaces, while permitting
> proprietary development beyond the reference, and crediting the
> authors of code and other work products for their efforts. The
> current TinyOS code base on SourceForge carries a small set of
> variants of the BSD license in which the Copyright is held by the
> author's institution. The Alliance will authorize a small set of
> templates for use in code that it distributes. Alliance rules
> stipulate that use of the code or other work products for commercial
> products, research reports, or social good should give credit to the
> authors and tools will be provided to facilitate such creditation.
>
> Organizational Structure
>
> The core of the Alliance organization is the working groups (WG). Each
> has
> a chair, membership, and charter. Overseeing the working groups is a
> Steering committee (SC), composed of WG chairs and members elected at
> large. The SC establishes WG policy, manages WG creation,
> termination, and arbitration, and supervise activities to resolve
> conflicting directions and move the process towards overall
> architectural harmony. It also recognizes individuals and institutions
> as Contributing Members. Working Groups may be longstanding or
> short-term and may be chartered by the SC or formed from grass roots
> efforts. As a non-profit, the Alliance also has a director, a board,
> and modest adminstrative support. Almost all positions in the Alliance
> will be on a volunteer basis.
>
> Alliance Working Group
>
> David Culler (Ch) - UCB/ArchedRock culler at cs.berkeley.edu
> Philippe Bonnet - Diku bonnet.p at gmail.com
> Deborah Estrin - UCLA destrin at cs.ucla.edu
> Ramesh Govindan - USC ramesh at usc.edu
> Mike Horton - Crossbow mhorton at xbow.com
> Jeonghoon Kang - KETI budge at keti.re.kr
> Philip Levis - Stanford pal at cs.stanford.edu
> Lama Nachman - Intel lama.nachman at intel.com
> Jack Stankovic - UVA stankovic at cs.virginia.edu
> Rob Szewczyk - Moteiv rob at moteiv.com
> Matt Welsh - Harvard mdw at cs.harvard.edu
> Adam Wolisz - TU Berlin awo at ieee.org
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
More information about the Tinyos-devel
mailing list