TinyOS is an operating system for mote-based wireless sensor networks. TinyOS code (and user applications) are written in the nesC language, which is an extension of C that adds components, interfaces, and some compile-time concurrency analysis to detect possible race conditions. TinyOS programming tends to have a steep learning curve; in addition to learning a new language, developers have to program using very fine grained events. For people who have C or Java idioms ingrained in their programming style, the combination of these changes can make TinyOS programming frustrating.

nesC is a derivative of C, so the challenge is rarely writing code on the level of a function or structure. Instead, the differences between TinyOS programming and traditional systems programming appear at the level of composition. For example, TinyOS programming doesn't support dynamic memory allocation: the idea is that all state a program needs should be allocated statically, in order to preclude run-time corner cases from causing hard to diagnose failures. As components are always singletons (in nesC 1.0 and 1.1), creating multiple instances of a service at compile time (say, five components each need their own Timer) requires uses some nesC-specific features that have no clear analogues in C.

This web page is intended to be an introduction to TinyOS programming at a structural level. The TinyOS tutorials cover the basics of nesC: the difference between a configuration and a module, interfaces, defaults, and unique(). However, they don't really discuss how you can use the features the language provides to build complex systems. Being the nesC language designers and significant contributors to TinyOS, we've come across several TinyOS design patterns, or generic uses of nesC's functionality which simplify building complex TinyOS systems.

This web page describes design patterns that we and others have encountered, with the hope that the TinyOS community can benefit from their use. These by no means are the complete set of patterns: there are many more out there that haven't been encountered yet, or which the current state of sensor network development haven't yet needed. It's certainly the case that others have discovered design patterns that we haven't, and we'd love to hear your experiences. If you have a design pattern you'd like listed here, please read the contribution guidelines.

Design Patterns