24-01-2013, 12:05 PM
TinyOS – An Operating System for Tiny Embedded Networked Sensors
1TinyOS.pdf (Size: 875.32 KB / Downloads: 69)
ABSTRACT
This paper discusses the background and application requirements that motivated the development of TinyOS. It enumerates the characteristics associated with any typical Networked Sensor application. The hardware platform that was used for deploying TinyOS is also described. The design aspects of the Event based TinyOS is discussed in detail. This paper also enlightens the Tiny Active Messaging Model used by the TinyOS for data communication and its implementation concepts. The paper goes ahead and describes some application level communication concepts like managing packet buffers, Network discovery and Ad Hoc Routing and Media Access and Transmission Control. Then there is a bunch of discussions that includes topics like Evaluation of TinyOS, Comparison of TinyOS with other Operating Systems and Future Research Work.
INTRODUCTION
Background
TinyOS is anevent basedoperating environment that is designed for use withembedded networkedsensors [1].It is designed to support the concurrency intensive operations required by networked sensorswith minimal hardware requirements. It uses the Active Message Communication model [2] for building non-blocking applications and higher Networking capabilities likeMultihop ad hoc routing. TinyOS wasdeveloped by a group of four Computer Science Graduate Students at the University of California,Berkeley. The development of TinyOS was supported by Defense Advanced Research Project Agency (DARPA), the National Science Foundation (NSF) and Intel Corporation.[5] [1]
These Embedded Sensors are characterized to be agile, self-organizing, critically resource constrainedand communication centric. Their application space is huge including all monitoring applications in acontext aware situation, situation monitoring of life science experiments, disaster management and others. There are two design issues associated with this scenario: these devices are Concurrency Intensive where several flows of data must be handled simultaneously and the system must provide Efficient Modularity, which means that hardware specific and application specific components must coalesce together with little processing and storage overhead [2]. There are bursts of activity where data and events stream in from the sensors and the Network and periods of passive listening to significant events. During the bursts a mix of real time actions and long-scale processing/computation must be performed and in the remaining majority of time, the device shuts to a very low power state and monitors for changes in the system state.
Hardware Organization
The UC-Berkeley group developed a small, flexible networked sensor platform that expressed the key characteristics of the general class (in Section 2.2). Figure 1 shows the hardware configuration of the device.
There is a microcontroller MCU (ATMEL 90LS8535) that has an 8-bit Harvard Architecture processor with 16- bit addresses. It has 32 8-bit general registers and runs at 4 MHz and 3.0 Volts. It has 8 KB of Flash Program Memory and 512 Bytes of SRAM as the data memory.
TinyOS Design
TinyOS uses an Event model so that high levels of concurrency can be handled in a very small amount of space unlike the stack based threaded approach that uses too much stack space and also has a high context switch time. [1]
Since Power is a precious resource, CPU resources must be utilized efficiently. The event-based approach handles tasks associated with events rapidly without allowing blocking or polling. Unused CPU cycles are spent in sleep state as opposed to actively looking for events. TinyOS was developed in C. [3]
Components, Commands, Events and Tasks
TinyOS is divided into a collection of Software Components. A TinyOS application consists of a scheduler and a graph of components describing their interaction.
A Component has four parts: a set of Command Handlers, a set of Event Handlers, an encapsulated fixed-size frame and a bundle of simple tasks. Each component declares the commands it uses and events it signals. [1] [7]
The fixed sized frames are statically allocated which helps to know the memory requirements of a component at compile time. The frame is an internal storage space that contains the state of the component and is used by the events, commands and tasks.
LOWER LEVEL COMMUNICATION
CHALLENGES
Crossing layers without buffering
Because of the memory constraints, the message data from the application storage buffer
has to be moved to the physical modulation of the channel without making entire copies,
and similarly in the reverse direction. [2]
The upper component has a unit of data partitioned into subunits. It issues a command to
request transmission of the first subunit. The lower component acknowledges that it has
accepted the subunit and when it is ready for the next one it signals a subunit event. The
upper handler provides the next unit, or indicates that no more are forthcoming. Thus the
same buffer is re-used from one layer to another without copying. The same holds for
building up data from the lower level components to the higher level ones. [3]