1. TinyOS: An Operating System for Sensor Networks
EEL 6935 Embedded Systems
Long Presentation 1
Group Member: Qin Chen, Xiang Mao
In this presentation, I am going to talk an operating system for wireless sensor nodes. The reason I chose this topic is because we know that from HW’s perspective, sensor is very different from general desktops. It has to be power and cost efficient. And it needs to be robust and reliable.
As for the SW that is on top this HW constraints, it must have some unique aspects as compared to general desktop OS. I am curious about these differences. And I chose TinyOS, which is a widely used OS for sensor networks.
2/5/2010

2. Outline Motivation Design Performance Applications Summary
Sensor node (mote) specifications
Four requirements
Design
Meet the four requirements
Performance
Applications
Summary
This is the outline of this presentation.
Hopefully, by the end of this presentation, you can get an idea of the unique requirement of a sensor network OS and how TinyOS meets these requirements.
2/5/2010

3. Mote HW specifications Program memory: 128 KB RAM: 4 KB
Power: two AA batteries
Size: 1 by 1 inch
Data rate: 38.4 kbps
Two motes from UCB family: Mica2 and Mica2Dot
2/5/2010

4. Motivation Why a new OS for sensor networks? Limited resources
Small size, low cost and power consumption
Reactive concurrency
Many tasks
Real-time
Flexibility
HW and application variations
Low power
Low power operations
Flexible power management strategies
Four broad requirements motivate the design of TinyOS
Small size, low cost, and low power consumption translated to limited resource requirements.
Currently a sensor node, or a motes consists of
Less than 5mm^2
1 MIPS processor
10 kB storage
And new technologies seem to reduce size and cost, rather than increasing the capabilities.
In a typical sensor network application, a node may perform several tasks, which may include
Sample its environments
Manipulate actuators
Perform data process
Transmit data
Routing data
Many of these tasks require real-time responses and concurrency management.
The variation in HW and application require a flexible OS that is both application specific to reduce space and power, and independent of the boundary between HW and SW.
Lower power consumption is always the top requirement for a sensor node design. A successful OS shall provide extremely low power operation and flexible power management strategies.
2/5/2010

5. TinyOS Open source Component based architecture
Collaboration between UC, Berkeley, Intel, and Crossbow Technology
Widely used by over a hundred groups worldwide
Component based architecture
Programming language: nesC
Supported development environment: Linux and Windows
TinyOS is one among the answers to these requirements. Here are some basic facts of TinyOS.
It is a free and open source operating system. It is a result from the collaboration between UCB, Intel and Crossbow. It has been widely used by over a hundred groups worldwide.
It features a component based architecture, which is critical for meeting the limited resource, concurrency, and flexibility requirements. We will go into its details soon.
It uses NesC as its programming language, which is an extension of C.
TinyOS applications can be developed under Linux and Windows with Cygwin support.
2/5/2010

6. Application (User Components) Main (includes Scheduler)
Main Concept
Application = Collection of components + scheduler
Compiled into a single executable
Event-driven architecture
Single shared stack
Communication
Actuating
Sensing
Application (User Components)
Main (includes Scheduler)
Hardware Abstractions
This figure shows the main concept of TinyOS. At the bottom is HW abstractions. On top of them are modules that perform independent tasks, like sensing, actuating, and communicating. This modules are called “component” in TinyOS’s terminology.
An application is basically a collection of components to perform a particular task. And an application is compiled into a single executable. And it has a simple scheduler, which I will cover later.
TinyOS features an event-driven architecture and uses a single share stack.
2/5/2010

7. Component Model Component Computation entity
Abstraction of HW resources
Three abstractions
Command: downcall
Event: upcall
Task: computation
Split-phase
Interface
Modules and configurations
Component
Event
Command
Interface
Task
Here we start some details of TinyOS design. One of the most important concept of TinyOS is component.
As we just said, TinyOS program is a graph of component, each of which is an independent computation entity. A component can be entirely software based, or it can be an abstraction of a HW resource. The distinction is transparent to programmer. This flexibility facilitates power efficient design.
Each component exposes one or more interfaces. A component provides and uses interfaces. A single component may use or provide multiple interfaces and multiple instances of the same interface.
Command and event for inter-component communications. A command is a request to a component to perform some services, such as initiating a sensor reading. An event signals the completion of the services. Commands and events cannot block: rather, a request for service is split phase, i.e., command and event are decoupled, i.e., command returns immediately and event signals completion at a later time.
Tasks perform the actual extensive computation. This has the nice property that you don’t need to worry about tasks interfering with one another and corrupting each other’s data. However, it also means that tasks should usually be reasonably short. If a component has a very long computation to do, it should break it up into multiple tasks.
Split-phase: run-to-completion does not work well for large computations. A component needs to be able to split a large computation into smaller parts, which can be executed one at a time. Also, there are times when a component needs to do something, but it's fine to do it a little later. Giving TinyOS the ability to defer the computation until later can let it deal with everything else that's waiting first.
There are two types of components: modules and configurations. A module is an individual component while a configuration is a collection of components. Configurations allow multiple components to be assembled together into a single super-component that exposes a single set of interfaces.
Interface
Command
Event
2/5/2010 7

8. Component Library Network protocols Distributed services
Sensor drivers
Data acquisition tools
Timers
Storage
The TinyOS base consists of 401 components.
They can be used to build specific systems for different applications.
2/5/2010

9. Execution Model Tasks Interrupt handlers
Run-to-completion
Non-preemptive FIFO scheduling
Atomic to each other
Interrupt handlers
Signaled asynchronously by HW
CAN preempt tasks
NesC compiler prevents nearly all data races
Preempt
Tasks
POST
FIFO
events
commands
commands
Interrupts
Time
Hardware
Run-to-completion: This simple mechanism allows the TinyOS scheduler to minimize its RAM consumption and keeps sync code very simple. However, it means that if one piece of sync code runs for a long time, it prevents other sync code from running, which can adversely affect system responsiveness.
A component can post a task in a command, an event, or a task. The post operation places the task on an internal task queue which is processed in FIFO order. When a task is executed, it runs to completion before the next task is run.
The data race prevention has two impacts. First, it eliminates a class of very painful non-deterministic bugs. Second, component composition can ignore which components generate concurrency or how they are wired together: the compiler catch any sharing violations at compile time.
2/5/2010

10. Network Messages Active message (AM)
36-byte packet with a 1-byte handler ID
Event-driven
Handlers are registered to receive messages of a particular type
Provides an unreliable, single-hop datagram protocol
Higher-level protocol and multi-hop communication are built on top of the AM interface
Networking architecture is a critical aspect of any sensor network OS. Here give some details of TinyOS’s networking design.
Unlike general desktop OS, which uses socket/TCP/IP packets for networking, TinyOS uses so called active message.
It is event-driven: upon reception of an active message, a node dispatches the message to one or more handlers that are registered to receive message of this type.
2/5/2010

11. Comparison with Linux Linux TinyOS Scheduling Preemptive, priority
Non-preemptive FIFO
Concurrency
Process/thread
Task
IPC
Pipe, socket, semaphore NA
Networking
Socket/TCP/UDP/IP
Active massage
MMU
Yes
I/O
Blocking
Split-phase
Kernel/user space
Here I list some design comparison between Linux and TinyOS. In following part, I will show how the design of TinyOS meet the low cost, low power requirements posed by sensor networks
Scheduling: 1. simpler scheduler  smaller code size; 2. non-preemptive  smaller memory usage and code size, and data race prevention.
Concurrency: The problem with threads in embedded systems is that they require a good deal of RAM. Each thread has its own private stack which has to be stored when a thread is waiting or idle.
MMU: programs running on mote are usually very application specific and it is very unlikely that we will need run programs that are not relevant to the application. So it nature to exclude this support. 1) increased responsiveness; 2) reduced memory/stack usage.
I/O: In a split-phase system, when a program calls a long-running operation, the call returns immediately, and the called abstraction issues a callback when it completes. 1. smaller memory usage.
Kernel/user space: As most mote platforms do not have hardware-based memory protection, there is no separation between a "user" address space and a "system" address space; there is only one address space that all components share.
2/5/2010

12. Req 1: Limited Resources
Absolute size
Components are resolved at compile time
Application specific version
Base TinyOS < 1KB
Most applications < 16 KB
TinyDB < 64 KB (largest TinyOS application)
Footprint Optimization
Stripping symbol table
Prune dead code
Cross-component optimization
Size improvement: 8% -- 60%
A TinyOS program’s component graph defines which component it needs to work. Compiling an application builds an application-specific version of TinyOS: the resulting image contains exactly the required OS services.
Beyond the standard technique to reduce code size, e.g., stripping symbol table, TinyOS uses whole-program compilation to prune dead codes. It also uses cross-component optimization to remove redundant operations and module-crossing overhead. [inline, cross module overhead: function calls; constant propagation, common sub-expression elimination]
2/5/2010

13. Req 2: Reactive Concurrency
Concurrency exhibited by applications
Example: TinyDB
Race detection
Context switch
Task scheduling
Interrupt handler overhead
Real-time constraints
Burst of activities + lengthy idle interval
Time critical work + task
TinyOS’s component model makes it simple to express the complex concurrent actions in sensor network applications.
TinyDB is an example of a high-concurrency application. It is a in-network query processing engine that allows users to pose queries that collect, combine, and filter data from sensor network. It supports multiple concurrent queries.
In TinyOS, context switch overhead includes both the cost of task scheduling and interrupt handler overhead. It quite light-weight as compared general desktop OS, which may including overhead like saving page table, process control table, etc.
As for the real-time constraints, sensor nodes exhibit bursts of activity and then go idle for lengthy intervals. While processing sensor data and routing traffic, hard deadline in serving the radio channel must be met. This is achieved by a handler that performs the time-critical work and then posts a task for remaining work. Scheduling is in FIFO fashion.
2/5/2010

14. Req 3: Flexibility Fine-grained components HW/SW transparency
Interposition
TinyOS allows applications to be constructed from a large number of very fine-grained components. Under TinyOS source tree, there are 42 applications and they use an average of 74 components.
As we just mentioned, any component can be the source of concurrency. NesC compiler removes the need to worry about concurrency bugs during composition by static race detection.
The TinyOS component model makes shifting the HW/SW boundary easy. Component can generate events, which may be SW upcalls or HW interrupts. In the TinyOS code base, some SW components are supplanted with specialized HW modules. In some cases, HW interfaces are implemented by SW wrappers to hide the complexity.
One aspect of flexibility is the ability to interpose components between other components. Whenever a component provides and uses the same interface type, it can be inserted or removed transparently. This feature eases the difficulty of application upgrading.
2/5/2010

15. Req 4: Low Power Application specific CPU power usage
Split-phase operation
Event driven execution
Low-power sleep mode
Power management interface
Stop and start command
15 days years
HW/SW transparency
Replace SW components with HW ones
The application-specific nature of TinyOS ensures that no unnecessary functions consume energy. However this aspect along does not ensure low power operation.
The use of split-phase operations and an event-driven execution model reduces power usage by avoiding spinlocks and heave-weight concurrency (e.g. threads).
To minimize CPU usage, the TinyOS scheduler puts the processor into a low-power sleep mode when ever the task queue is empty.
The scheduler is at the highest level, and TinyOS provides finer-gained scheme for power management. It provides a interface that can put subsystems to a low power idle state.
Calling the stop command causes a component to attempt to minimize its power consumption, e.g., by powering down HW or disabling periodic tasks.
The component saves its state in RAM for later resumption using the “start” command.
A pair of AA batteries can power a constantly active node for up to 15 days or a permanently idle node for up to 5 years.
This is used in many levels, e.g. disabling the radio stack when no communication is expected, or powering down sensors when not in use.
The power saving results are impressive: a pair of AA batteries can power a constantly active node for up to 15 days or a permanently idle node for up to 5 years.
The ability to replace SW components with efficient HW implementations has been exploited to yield significant improvements in energy consumption. For example, a HW implementation of a radio stack can provides 30 times less power consumption while providing a 25-fold improvement in bit rate, as compared to its standard SW counterpart.
2/5/2010

16. Applications Habitat monitoring Object tracking TinyDB Low power
Robust
Object tracking
High concurrency: routing, data sharing, time sync, localization, power management, and sensor filtering
TinyDB
Largest and most complex application
Concurrency control
Limited resources
Each of these applications represents a distinct set of design goals and exhibits different aspects of the TinyOS design.
To achieve long network lifetimes, nodes used the power management facilities of TinyOS aggressively
Nodes sampled sensors concurrently (using a split-phase data acquisition operation), rather than serially, resulting in further power reduction.
TinyOS execution model enables running these services concurrently on limited hardware resources.
The component model allows for easy replacement and comparative analysis of individual services.
TinyDB relies heavily on TinyOS’ component-oriented design, concurrency primitives, and ability to perform cross-layer optimizations.
The non-preemptive nature of tasks and the support for safe concurrent handlers avoid data races despite extensive information sharing.
2/5/2010

17. Summary Small memory footprint Power efficient Efficient modularity
Application specific
Non-preemptive FIFO task scheduling
Power efficient
Multi-level power management
Efficient modularity
Component architecture
Function call (event, command) interface between components
To conclude, TinyOS is a very compact, power efficient, and flexible OS that is suitable for extremely resource-constrained sensor nodes.
2/5/2010

18. Improvements
FIFO scheduling  shortest first? Earliest deadline first, etc?
Of course, all there improvements may not come free. They may result in bigger code size, or larger memory footprint. What is more important is to investigate the specifications and requirements, and make proper trade-offs.
2/5/2010

19. References
TinyOS: An Operating System for Sensor Networks, Ambient Intelligence, 2005
TinyOS tutorials,
2/5/2010

20. Questions? 1. Please list four requirements that TinyOS try to meet.
2. Please list three aspects of TinyOS that are different from general desktop OS (e.g. Linux).
3. What is a “component” in TinyOS? What are “command” and “event” of a component used for?
4. Why ?
2/5/2010