Log in
  
Home > Networking & Communications
Related topics: Networking & Communications,Feature, Intelligent Systems, Sensors Mag, Software, Standards & Protocols, Technologies in Depth, Wireless
Networking & Communications

TinyOS: Operating System Design for Wireless Sensor Networks

May 1, 2006 By: PhD , David E. Culler, PhD, Arch Rock Corp. Sensors

Meet the OS designed to ease development of robust software applications for wireless sensor networks.


TinyOS has been adopted by thousands of developers worldwide, on many platforms, for a broad range of wireless sensor networks. Its communication-centric design and modular software model are tailored to the unique requirements of these networks, where applications and services are distributed over collections of resource-constrained, unattended application-specific devices streaming data to and from the physical world. From its roots in the academic research community, it is emerging as an important vehicle for commercial deployments.

The role of any operating system (OS) is to promote development of reliable application software by providing a convenient and safe abstraction of hardware resources. In PCs and servers, the OS allocates application processing threads to processors, maps virtual addresses to locations in memory, and manipulates disks, networks, and peripherals on the application's behalf.


This OS/application division—essential in conventional computing—is less common in the embedded world of sensing and control, where applications are tightly bound to particular hardware and weave in high-level logic with manipulation of the physical apparatus. This is due to very limited hardware resources; highly specialized applications; and long, stringent, development cycles often dominated by mechanical and other factors.

Wireless sensor networks (WSNs) are embedded but general-purpose, supporting a variety of applications, incorporating heterogeneous components, and capable of rapid deployment in new environments. Wireless networking requires greater concurrent processing than wired protocols; while a WSN node is carrying out its normal data acquisition and processing steps, it also needs to service protocol events and packet transfers that arise asynchronously from the network. However, hardware resources remain diverse and constrained, especially in terms of memory and power. A sample of WSN platforms is shown in Figure 1. A typical TinyOS 'mote' platform has 10 KB of RAM, 100 KB of ROM, and consumes 10 μA to 25 mA, depending on which components are active.

Figure 1. Comparison of TinyOS platforms
Figure 1. Comparison of TinyOS platforms

TinyOS was designed specifically for WSNs. It introduces a structured event-driven execution model and a component-based software design that supports a high degree of concurrency in a small footprint, enhances robustness, and minimizes power consumption while facilitating implementation of sophisticated protocols and algorithms. The system and its services comprise components connected with well-defined interfaces, much as a schematic wires hardware blocks together. The diversity of hardware platforms, protocols, and applications is addressed by plugging together the necessary components from a catalog of candidates.

 

TinyOS Design

 

Resource Constrained Concurrency. Concurrency is a key system software challenge. The system manages several devices, e.g., ADCs, sensors, Flash memory, and radio. Typically, an operation is started on a device, which then runs concurrently with the main processor until generating a response. Meanwhile, other devices may also need service, requiring the system to juggle several event streams. A conventional OS uses multiple threads, each with its own stack. The thread dedicated to a device issues a command and then sleeps or polls until the operation completes. The OS switches among threads by saving and restoring their registers, and threads coordinate with others by using shared variables as flags and semaphores. This works for complex software on powerful machines but is problematic for embedded designs because multiple stacks must be kept in memory and each thread can potentially interact with any other whenever it accesses a shared variable. This can lead to subtle race conditions and deadlocks, requiring complex schedulers to meet real-time requirements and deadlines.

Event-driven execution is common in embedded systems because it permits a small footprint and more control over scheduling. A single stack supports many concurrent activities. The system is organized around a dispatcher that calls specific event-handlers, depending on the event type and the state of the system. Each handler takes immediate action (e.g., accessing a device) and updates the system state. Later events trigger subsequent operations. The drawback is that even small changes may require the developer to understand and possibly modify the overall structure, making code reuse, customization, and incremental evolution difficult.

1 2 3 4 5






Sensors.tv