TinyOS 2.0

A sensor network operating system has to be efficient, flexible, and reliable. Energy contraints mean that nodes not only have limited resources, but they must use those resources sparingly. As deployments are application domain specific, a flexible OS lets software make the most of these limited resources in order to meet that applications requirements without inefficiencies introduced by generality. Finally, in order for deployments to last unattended for long periods of time, the underlying OS must be stable and reliable. The past five years have seen tremendous research and technological developments in wireless sensor networks. The TinyOS operating system has been able to adapt and grow with this progress. However, five years of experience have shown that some of its structure and abstractions to be problematic. The huge existing TinyOS codebase means that changing basic aspects of the OS would break all of this existing work. This has led us to develop TinyOS 2.0, a second-generation mote operating system. TinyOS 2.0 keeps many of the basic ideas in TinyOS 1.x: it is a component-based operating system written in the nesC language [1]. However, it is a clean-slate rewrite of the entire OS. Every major subystem has a corresponding TEP (TinyOS Enhancement Proposal) document, which describes the design and structure of the subsystem and documents a sample implementation. TEPs are open to review and comment from the larger community. As having a broad base of experience is important to guide design and implementations, the TinyOS 2.0 Working Group (WG) includes developers from UC Berkeley, TU Berlin, Stanford, UCLA, Crossbow, Moteiv, Arched Rock and Intel. TinyOS 2.0 pushes forward in three key areas: greater platform flexibility, improved robustness and reliability, and the concept of service distributions. The first is intended to simplify platform development and interoperability, the second is a general design goal, and the last simplifies application development. TinyOS 2.0 supports greater platform flexibility in two ways. First, it introduces a three-layer Hardware Abstraction Architecture (HAA) [2]. The bottom layer is the Hardware Presentation Layer (HPL), which provides access to basic resources, such as registers, interrupts, and pins, through nesC interfaces. The middle layer is the Hardware Abstraction Layer (HAL), which has higher-level interfaces that provide useful abstractions of the full capabilities of the underlying hardware. The top layer is the Hardware Independent Layer (HIL), which presents abstractions that are hardware independent and therefore cross-platform. Second, TinyOS 2.0 uses version 1.2 of the nesC language, which has new features to better support cross-platform networking. nesC