TinyOS: Operating System Design for Wireless Sensor Networks

From: http://www.sensorsmag.com/sensors/content/printContentPopup.jsp?id=324975#

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

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.

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.

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.

Structured Event-Driven Execution. TinyOS provides a structured event-driven model. A complete system configuration is formed by 'wiring' together a set of components for a target platform and application domain. Components are restricted objects with well-defined interfaces, internal state, and internal concurrency. Primitive components encapsulate hardware elements, e.g., radio, ADC, timer, or bus. Their interface reflects the hardware operations and interrupts; the state and concurrency is that of the physical device. Higher-level components encapsulate software functionality, but with a similar abstraction. They provide commands, signal events, and have internal handlers, task threads, and state variables.

This approach accommodates hardware evolution, including major changes in the hardware/software boundary, by component replacements. Its memory footprint is small, despite supporting extensive concurrency, requiring only a single stack and a small task queue. However, the modular construction provides flexibility, robustness, and ease of programming. A restricted form of thread, called a task, is available within each component, but interactions across components are through explicit command/event interfaces. The wiring of components and the higher priority of asynchronous events over tasks permit the use of simple schedulers—and in TinyOS 2.0 even the scheduler is replaceable.

Components and Bidirectional Interfaces. TinyOS is written in ANSI standard C with support for component composition, system-wide analysis, and network data types. A component has a set of bidirectional command/ event interfaces implemented either directly or by wiring a collection of subcomponents. The compiler optimizes the entire hierarchical graph, validates that it is free of race conditions and deadlocks, and sizes resources. The TinyOS community has produced plug-ins for integrated development environments and several visual programming environments for this component-based programming style.

Network data types simplify protocol implementation. While network packets have a particular specified format, data representation in a computer program depends on word width and addressing of the host processor (little or big endian), so most protocol code contains machine-dependent bit-twiddling and run-time parsing. Because TinyOS uses network types with a completely specified representation, the compiler provides efficient access to packet fields on embedded nodes, as well as Java and XML methods for packet handling on conventional computers and gateways.

Split-phase operations are a typical use of bidirectional interfaces. A higher-level component issues a command to initiate activity in a hardware or software component. The command returns immediately, indicating the status of the request, even though the operation takes some time to complete. When done, the operating component signals an event to components that will take further action. Meanwhile, the processor may service other tasks and events, or sleep if no tasks are pending. Thus, interleaved execution and power management is provided systematically throughout the entire set of TinyOS components.

Application-Specific Platform Support

Figure 2. Typical Arch Rock TinyOS 2.0 configuration

Sensing. Conventional systems are customized for particular peripherals with device drivers. In WSNs, various sensors may be used with a common platform. TinyOS 2.0 provides sensor drivers, which scale from low-rate, low-power sampling of environmental factors to high-rate, low-jitter sampling of vibration or acceleration. Drivers handle warm-up, acquisition, arbitration, and interface specifics. Since sensor selection is closely tied to the application and mechanical design, drivers must be easily configured and tested, rather than dynamically loaded after market.

Communications. Communications and networking have driven the TinyOS design as available radios and microcontroller interfaces evolved. The communication subsystem has to meet real-time requirements and respond to asynchronous events while other devices and processes are serviced. Early designs modulated the radio channel bit-by-bit in software, while the Mica and Mica2 generations used a byte-level interface. Most recent platforms use IEEE 802.15.4 radios, such as the ChipCon CC2420, with a packet-level interface, but with differing microcontroller-radio interconnections. The TinyOS 2.0 radio component provides a uniform interface to the full capabilities of the radio chip. The link-level component provides rich media access control (MAC) capabilities, including channel activity detection, collision avoidance, data transfer, scheduling, and power management, allowing networking components to optimize for specific protocols. Several platforms use other radios, including those from Nordic, Infineon, and Freescale, and many provide wired links for gateways, serial-based peripherals, or federations of microcontrollers. Packet transmission and reception is reflected in the TinyOS execution model; send is split-phase with a send-done event, whereas receive generates a packet-arrival event.

Storage. Nonvolatile storage is used in WSNs for logging, configuration parameters, files, and program images. Several different kinds of Flash memory are used with different interfaces and different protocols. Lower-layer TinyOS components provide a block storage abstraction for various Flash chips and platform configurations, with one or more application-level data services provided on this substrate.

Embedded Application Services

Networking. The TinyOS community has developed networking layers targeted at different applications with different techniques for discovery, routing, power reduction, reliability, and congestion control. These networking layers provide higher-level communication services to embedded applications with a TinyOS programming interface. The most widely used services for WSNs are reliable dissemination, aggregate data collection, and directed routing.

Reliable dissemination provides guaranteed delivery of messages from a source, typically a gateway, to some or all nodes in the network. It is used for network configuration and control, so it doesn't depend on any pre-established neighbor discovery, routing, or connection setup. Each dissemination operation causes a series of packet transmissions to propagate across the network, updating the nodes with a new command or value. When a node receives an update, it selectively retransmits it to distant nodes. Nodes may be obstructed, out of range, or powered off when the update is initiated, so continued infrequent retransmission ensures that all nodes are eventually up to date. Should the network be very dense, say when thousands of nodes are on a shipping dock, nodes will suppress their retransmissions when they hear from others. Reliability is obtained through network redundancy and data consistency management, rather than through active acknowledgements.

To collect and aggregate data from the WSN, nodes cooperate in building and maintaining one or more collection trees, rooted at a gateway or data sink. Each node gathers link-quality statistics and routing cost estimates through all kinds of communication, including routing beacons, packet forwarding, and passive traffic monitoring. It uses this information to continuously select the best from its candidate routing parents, to which it forwards its own data as well as packets received from its children. Since the number of nodes within communication range may vary widely, these tree-formation and routing algorithms must be designed with a fixed-size neighbor table for any network.

Similarly, a node can establish a route to any other node in the network and have packets forwarded hop-by-hop to the destination. Such directed routing is most often used to issue commands to a particular node, transfer bulk data, and in network management.

Network Services. Typically, a TinyOS application is a concise program built upon a set of system services and reflecting the processing logic of its particular domain. It opens sensor drivers, sets sample rates, and performs local processing on data streams. It may also spool raw or processed data to logs. It uses network-wide communication services to share information with other nodes and with the outside world. Both the embedded application and the system itself can be reprogrammed over-the-air using density-aware reliable dissemination into Flash memory.

Most embedded applications can be generalized to support a variety of uses in a particular domain. For example, in environmental monitoring the sample rate, down-sampling interval, and alert thresholds are natural configuration parameters. With an annotation in the application, Arch Rock TinyOS tools will generate the Web Service infrastructure, as well as the embedded application support, to make these parameters accessible to the IT enterprise. Similarly, the alerts are posted to the Web Service environment. Sophisticated application engines, such as TinyDB, provide a simple database query processor on each node, accessible through SQL commands,while application-specific virtual machines, such as Maté, execute simple scripts that are disseminated over the network.

Evolving in the Open

As wireless sensor network technology matures, it promises the ability to instrument the world at a fidelity that was previously impractical and to monitor points and phenomena that were previously unobservable, due to inaccessibility, mobility, or physical distance. It is the confluence of several technological advances; semiconductor fabrication has provided powerful microcontrollers, low-power radios, and mass-produced sensors. Algorithm development and empirical study have provided effective mesh routing protocols. Finally, TinyOS provides an execution environment in which protocols are implemented to provide powerful services on rapidly advancing hardware in support of increasingly sophisticated applications.

Figure 3. Summary of recent TinyOS download history

Sun SPOT: A New Twist

Figure 4. Sun Lab s Sun SPOT system

The Squawk Virtual Machine supports a Java subset and provides conventional system capabilities, including thread scheduling, memory management, and interrupt handling. The sensor drivers, communications, and Flash storage subsystems are written in Java. Application classes use these libraries and higher-level communication services and a restricted form of threads is used in system code.

The virtual machine occupies 80 KB of RAM and the system libraries 270 KB of ROM. The Sun SPOT hardware is similar to the Intel Mote2, with roughly 20 × the memory of a typical TinyOS platform. It consumes 25–90 mA, as compared to 0.01–25 mA for a Mica or Telos 'mote.'

For More Information

The main site for the TinyOS community is www.tinyos.net.

The TinyOS 2.0 working group can be found at www.tinyos.net/scoop/special/working_group_tinyos_2-0.

J. Hill, R. Szewcyk, A. Woo, D. Culler, S. Hollar, K. Pister, "System Architecture Directions for Networked Sensors," ASPLOS 2000, pp. 93–104.

V. Handziski, J. Polastre, J.H. Hauer, C. Sharp, A. Wolisz and D. Culler, "Flexible Hardware Abstraction for Wireless Sensor Networks," Proc 2nd European Workshop on Wireless Sensor Networks (EWSN 2005), Istanbul, Turkey, 2005.

P. Levis, TinyOS Programming, http://csl.stanford.edu/~pal/pubs/tinyos-programming-1-0.pdf.

P. Levis, D. Gay, V. Handziski, J.H. Hauer, B. Greenstein, M. Turon, J. Hui, K. Klues, C. Sharp, R. Szewczyk, J. Polastre, P. Buonadonna, L. Nachman, G. Tolle, D. Culler, and A. Wolisz, " T2: A Second Generation OS for Embedded Sensor Networks," Technical Report No. TKN-05-007, Telecommunication Networks Group, Technical University, Berlin, 2005.

David E. Culler, PhD, can be reached at Arch Rock Corp., San Francisco, CA; 415-692-0828, dculler@archrock.com, www.archrock.com