TinyOS -- An open-source OS for sensor networks First European TinyOS Technology Exchange (ETTX 2009),
February 10th, Cork, Ireland

TinyOS Site

WWW

Site menu
Downloads and Releases
    Installing TinyOS
    Release news

Documentation
    Documentation Wiki
    Using TinyOS
    TinyOS Tutorials

Support
    FAQ
    Mail List Archives

Development
    Working Groups
    Sourceforge CVS
    Report a Bug
    Contributing Code

Community
    TinyOS Alliance (PDF)
    Mailing Lists
    TTX
    TinyOS Projects
    User Statistics
    Job Postings
    TinyOS 1.1 (no active support)

News and Login
    News
    Create Account
     Submit Story (account required)

Login
Make a new account
Username:
Password:

TinyOS Working Groups
 
TinyOS is an open-source, open-community effort. As such, the design direction of TinyOS is directed as much as possible by working groups comprised of people with diverse experiences and backgrounds but a common interest in TinyOS.

Active
TinyOS TinyOS Alliance Working Group (alliance)
TinyOS Core Working Group (core)
TinyOS Network Protocol Working Group (net2)
Sensor Network Testbed Working Group (testbed)
Sensor Simulation Working Group (sim)
Storage Working Group (storage)
TinyOS 8051 Working Group (8051)
TinyOS Tools Working Group (tools)
TinyOS IEEE 802.15.4 Working Group (15.4)
TinyOS ZigBee Working Group (zigbee)

Recently Active
TinyOS 1.2 Working Group (tos1.2)

Completed
TinyOS Host Mote Working Group (host-mote)


Forming new Working Groups

The TinyOS Alliance provides a structure for individuals to become involved in the effort to establish and provide open code and protocols for embedded sensor networks. Working groups (WGs) are a major part of this structure. Working groups provide a forum for interested individuals from many different institutions and perspectives to collaborate on a common goal.

The TinyOS Alliance Steering Committee (SC) reviews proposals for the formation of new working groups, which should be sent to David Culler, the chair of the Alliance Working Group (culler AT eecs DOT berkeley DOT edu).

Working group proposals need not be long or verbose. Usually, a single page will do. A proposal should have 6 key pieces of information:

  1. Name: the proposed name of the working group.
  2. Charter: 1-3 sentences describing the scope and topic the group will work on.
  3. Members (and initial chair): A list of at least 3 people who will form the initial membership, as well as one additional person who will be the chair. The member list should include affiliations. While not a requirement, the SC strongly encourages that the initial member list include multiple perspectives. Working groups bring people together to work on a topic collaboratively; ideologically exclusive groups are contrary to this goal.
  4. Membership policy: A description of what process the group will use to admit new members. This can vary from group to group: core is based on consensus, net2 is voting, and alliance is invitation.
  5. Timeline: A description of the planned work products for the first six months or so. The purpose of the timeline is not to be a set of hard deadlines, rather to give more detail on the group's output goals as well as a general metric the group can use to assess its own progress. The timeline doesn't need to be aggressive.
  6. Overlap and Interactions: This identifies where and how work under the charter might overlap those of other working groups and how the new group plans to work with others.

Here is an example of what a proposal from net2 might look like if written in November 2006.

Working groups define the difference between what code is in tinyos-2.x-contrib and what code is in tinyos-2.x. A working group that includes implementations are part of its charter has one or more directories in the tinyos-2.x/ tree (generally but not always in tos/lib and doc/). Each directory is "owned" by a working group, who develops, improves, and maintains the code and documents therein. A working group confers with the core working group on how to name and were to put these directories. Generally, directories are created once a WG has files to check in, rather than when the WG forms.


TEPS
and the Authoring Working Groups
TEP Title Type Status Working Group
TEP 1 TEP Structure and Keywords Best Current Practice Finalized Core
TEP 2 Hardware Abstraction Architecture Best Current Practice Author Response Core
TEP 3 Coding Standard Best Current Practice Draft Core
TEP 101 Analog-to-Digital Converters (ADCs) Documentary Finalized Core
TEP 102 Timers Documentary Finalized Core
TEP 103 Permanent Data Storage (Flash) Documentary Finalized Core
TEP 106 Schedulers and Tasks Documentary Finalized Core
TEP 107 TinyOS 2.x Boot Sequence Documentary Finalized Core
TEP 108 Resource Arbitration Documentary Finalized Core
TEP 109 Sensor Boards Documentary Community Review Core
TEP 111 message_t Documentary Finalized Core
TEP 112 Microcontroller Power Management Documentary Community Review Core
TEP 113 Serial Communication Documentary Finalized Host-Mote and Core
TEP 114 SIDs: Source and Sink Independent Drivers Documentary Author Response Core
TEP 115 Power Management of Non-Virtualised Devices Documentary Finalized Core
TEP 116 Packet Protocols Documentary Finalized Core
TEP 117 Pins and Buses Documentary Finalized Core
TEP 118 Dissemination Documentary Finalized Net2
TEP 119 Collection Documentary Draft Net2
TEP 120 The TinyOS Alliance Informational Draft Alliance
TEP 121 Towards TinyOS for 8051 Informational Draft 8051
TEP 122 IEEE EUI-64 Unique Node Identifier Documentary Draft Core
TEP 123 The Collection Tree Protocol (CTP) Documentary Draft Net2
TEP 124 The Link Estimation Exchange Protocol (LEEP) Documentary Draft Net2
TEP 125 TinyOS 802.15.4 Frames Documentary Sent to SC Core

Comments are owned by the Poster. The Rest 2004 UC Berkeley.

create account | faq | search