1

TinyOSTinyOS

Sensors as SoftwareTinyOSTinyOS

Dario Rossidario.rossi@polito.it

TinyOSTinyOS

Motivation

• Sensor networks– Radically new computing environments– Rapidly evolving hardware technology

• The key missing technology…– …is system software to manage them efficiently

• TinyOS original goals – Prototype current generation sensors constructed from

off the shelf components.– Identify key requirements that an operating system for

such a sensor must satisfy.– Build an operating system meeting the requirements– Evaluate the operating system’s performance while

running a real application.

2

TinyOSTinyOS

Operating System Requirements

1. Small physical size and low power consumption

2. Concurrency intensive operation

3. Limited hardware parallelism and controller hierarchy

4. Diversity in design and usage

5. Robust Operation

TinyOSTinyOS

Operating System Requirements

1. Small physical size and low power consumption– Constrained processing, storage,

interconnection– Efficiently manage memory and CPU– Allow low power communications

2. Concurrency intensive operation– Little storage capability– Simultaneous data flows (sensing-data

gathering, manipulation and transmission)– Need to be able to service packets on-the-fly

3

TinyOSTinyOS

Operating System Requirements

3. Limited hardware parallelism and controller hierarchy– Limited number, and capability of controllers– Unsophisticated processor-memory-switch level

interconnect

4. Diversity in design and usage– Sensor will tend to be application specific, not general

purpose (use only required hardware)– Wide range of application -> large number of device– Need for modular architecture: build an application out

of a spectrum of reusable components– Migrate components across the hardware/software

boundary as the technology evolves.

TinyOSTinyOS

Operating System Requirements

5. Robust Operation– OS should be robust

• Devices will be numerous and largely unattended• Application are expected to be operational 24/7• OS failures will require to reboot the mote

– OS should ease the development of reliable distributed applications• Individual sensor failure should be tolerated• Assist applications in surviving individual device

failures

4

TinyOSTinyOS

The Solution: TinyOS

• A micro-threaded OS… – that draws on previous work… – done for lightweight thread support… – and efficient network interfaces

• Small, tightly integrated design– Convenient hardware abstractions– Crossover of software/hardware components– Scaling forward to future technology

TinyOSTinyOS

The Solution: TinyOS• An open-source development environment

– Features a set of common services– Thightly tied to the nesC programming language– Features several programming tools

• java• Makefile system• TOSSIM simulator• nesC

• Main Ideology– Make best use of most constrained asset: battery

• Hurry up and sleep !!– High concurrency, interrupt driven

• Two-levels scheduler

5

TinyOSTinyOS

TinyOS: Models and Performance

• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model

• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance

TinyOSTinyOS

TinyOS: Models and Performance

• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model

• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance

6

TinyOSTinyOS

Data Model• Static memory allocation

– No heap (malloc), function pointers– Static frame, fixed sized– Memory requirements known at

compile time– Increase runtime efficiency

• Global variables- Available on a per-frame basis

• Local variables– Saved on the stack– Declared within a method

TinyOSTinyOS

Thread Model

• Power-Aware Two-levels Scheduling– Long running tasks and interrupt events– Sleep unless tasks in queue, wakeup on event

• Tasks– Time-flexible, background jobs– Atomic with respect to other tasks– Can be prempted by events

• Events– Time-critical, shorter duration– Last-in first-out semantic (no priority)– Can post tasks for deferred execution

7

TinyOSTinyOS

Programming Model• Separation construction/composition• Construction of Modules

– Modules implementation similar to C coding– Programs are built out of components– Each component specifies an interface– Interfaces are “hooks” for wiring components

• Composition of Configurations– Configuration similar to VHDL desing– Components are statically wired together– Increases programming efficiency (code reuse)– Increases runtime efficiency (static defs.)

TinyOSTinyOS

Components Model: Terminology• Components

– Use and provide bidirectional interfaces– Call and implement commands– Signal and handle events

• Components – Must handle events of the used

interfaces (and can call commands) – Provide interfaces that must implement

commands (and can signal events)• Components

– Handle the events they are signaled– Implement the commands they provide

8

TinyOSTinyOS

Component Model: Scheme

• Component Interface– Command and Event– Frame (storage)– Tasks (computation)

• Component declares– The commands it uses – The events it signals

• Components– Handle the events they are signaled– Implement the commands they provide

Component FrameTask

Commands Events

Provides

Uses

Signals

Handles

TinyOSTinyOS

Component Model: Hierarchy• Commands

– Flow downward– Non blocking requests– Control returns to caller

• Events– Flow upwards– Post task, signal higher level

events, call lower level cmds– Control returns to signaler

• To avoid cycles– Events can call commands– Commands can NOT signal events

RFM (bit level)

Radio Byte

Radio Pkt

Commands Events

9

TinyOSTinyOS

Component Model: Hierarchy• Commands

– Flow downward– Non blocking requests– Control returns to caller

• Events– Flow upwards– Post task, signal higher level

events, call lower level cmds– Control returns to signaler

• To avoid cycles– Events can call commands– Commands can NOT signal events

RFM (bit level)

Radio Byte

Radio Pkt

Commands Events

Hardware Interrupt

TinyOSTinyOS

Component Model: Types• High level software

– Control, routing, data manipulation/aggregation.

• Synthetic hardware– Simulates advanced hardware– Could be cast in hardware– Need for flexible boundary

• Hardware abstraction– Map physical hardware into

TinyOS component model– Frame contains hardware state

RFM (bit level)

Radio Byte

Radio Pkt

Commands Events

10

TinyOSTinyOS

Component Model: Commands

• Goals and Means– Inter-component communication – Perform non-blocking requests to lower-level

components• Rules

– Can NOT signal events (to avoid cycles)– Can invoke lower level commands– Deposit request parameters into a frame…– … then post a task for later execution– Return status to the caller

TinyOSTinyOS

Component Model: Events

• Goals and Means– Directly deal with hardware interrupts– Propagate event-chain to upper components

• Rules– Can signal higher level events– Can invoke lower level commands– Deposit information into a frame… – …then post a task for later execution– Control returns to signaler– Can preempt events and tasks

11

TinyOSTinyOS

Component Model: Tasks

• Goals and Means– Intra-component primary computation work– Single OS stack assigned to the current task– Asynchronous with respect to events

• Rules– Can signal higher level events– Can invoke lower level commands– Can schedule other tasks within a component– Atomic with respect to other tasks– Can be pre-empted by events

TinyOSTinyOS

Component Model: TinyOS Code

Messaging Component

AM_S

UB_I

NIT

AM_S

UB_P

OWER

AM_S

UB_T

X_PA

CKET

AM_T

X_PA

CKET

_DON

E

AM_R

X_PA

CKET

_DON

E

Internal State

AM_I

NIT

AM_P

OWER

AM_S

END_

MSG

AM_M

SG_R

EC

AM_M

SG_S

END_

DONE

Internal Tasks

Commands Events

//AM.comp//TOS_MODULE AM;ACCEPTS{

char AM_SEND_MSG(char addr, char type,

char* data);void AM_POWER(char mode);char AM_INIT();

};SIGNALS{

char AM_MSG_REC(char type, char* data);

char AM_MSG_SEND_DONE(char success);};HANDLES{

char AM_TX_PACKET_DONE(char success);char AM_RX_PACKET_DONE(char* packet);

};USES{

char AM_SUB_TX_PACKET(char* data);void AM_SUB_POWER(char mode);char AM_SUB_INIT();

};Slide courtesy Jason Hill et al

12

TinyOSTinyOS

Network Model: General Idea

• Active Messages (AM)– Every AM triggers a specific event handler – Application-specific receiver-side action

TinyOSTinyOS

Network Model: Active Message

• Message is “active” because it contains – Destination Address

• 0xFFFF: broadcast• 0x007E: UART

– Message Type– Group ID

• Message format – 5 bytes header– 29-36 bytes payload– 2 bytes CRC

13

TinyOSTinyOS

Network Model: Message Exchange

TinyOSTinyOS

Putting It All Together

• Within a sensor– Scheduler is a power-aware FIFO queue– Peripherals can wake up the processor– Communication across components takes

the form of a function call. • Within the network

– Communication between components takes the form of Active Messages (AM)

– AM can wakeup/instruct/query sensors

14

TinyOSTinyOS

TinyOS: Models and Performance

• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model

• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance

TinyOSTinyOS

TinyOS: Models and Performance

TinyOS Performance• Simple multi-hop monitoring application• Check if original requirements are met

1. Small physical size and low power consumption

2. Concurrency intensive operation3. Limited hardware parallelism and controller

hierarchy4. Diversity in design and usage5. Robust Operation

15

TinyOSTinyOS

Test App: Goal

• Monitor temperature and light conditions• Periodically transmit measurements to a

base station•Sensors can act as relay(forward data for behalf of other sensors)

•Dynamically determine the correct routing topology

Image courtesy Jason Hill et al

TinyOSTinyOS

Test App: Ad hoc Routing

0Base

1

1

2

2

3

• Base sensor– periodically broadcasts route updates

• Any sensor in range of this broadcast– record the identity of the base station– re-broadcast the update

• Each sensor– remembers the first update received in an era– uses the source of the update as destination

Image courtesy Jason Hill et al

16

TinyOSTinyOS

Test App: Graph Component

Slide courtesy Jason Hill et al

RFM

Radio Byte

Radio Pkt

UART

Serial Pkt

I2C

Temp Photo

Active Messages

ClockBit

Byte

Packet

Ad hoc Routing Application

Application

HW

SW

ADC

TinyOSTinyOS

Evaluation: Small Physical Size

0

500

1000

1500

2000

2500

3000

3500

4000

Multihop RouterAM light

AM TempAMPacket

Radio ByteRFM

Photo

TempUART Packet

UART

i2cInit

TinyOS SchedulerC Runtime

• OS Scheduler• Code: 178 Bytes• Data: 16 Bytes

• Complete application• Code: 3 KBytes• Data: 226 Bytes • less than 50% of

the 512 Bytes totally available

• Only 3 components are required

17

TinyOSTinyOS

Evaluation: Small Physical Size

2263450Total

30160

17217882

Processor_initTinyOS schedulerC runtime

00

328

404081111

408

884078

1463563348103108464

196314198

Multihop routerAM_dispatchAM_temperatureAM_lightAMPacketRADIO_byteRFMPhotoTemperatureUARTUART_packetI2C_bus

Data Size (bytes)

Code Size (bytes)

Component Name

• OS Scheduler• Code: 178 Bytes• Data: 16 Bytes

• Complete application• Code: 3 KBytes• Data: 226 Bytes • less than 50% of

the 512 Bytes totally available

• Only 3 components are required

TinyOSTinyOS

Evaluation: Concurrency Intensive

12.259Interrupt (hardware cost)

17.75

2.52.5

11.512.75

2

Time (µs)

971Interrupt (software cost)

1.251.25

66

10104651

Post an EventCall a CommandPost a task to schedulerContext switch overhead

18Byte copy

Normalized to byte copy

Cost (cycles)

Operations• Low overhead: essential for modular efficiency

• Posting event: as copying 1 byte of data

• Cost of posting a task or context switchingis the same as copying 6 bytes of data

• Direct hardware-interrupt handling requires saving and storing registers

18

TinyOSTinyOS

Evaluation: Efficient Modularity• Packet transmission event (focus on last bit) • 5-layers propagation delay: 80 cycles, 40+55µs• 0: interrupt, 1-4: events, 5: command, 6: task

Timing diagram of event propagationSlide courtesy Jason Hill et al

TinyOSTinyOSEvaluation: Limited Hardware

Parallelism and Controller Hierarchy

• Multiple flows of data running through a single microcontroller

• Mostly idle even during RX/TX

ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)

AM 0.05% 0.02% 0.33Packet 1.12% 0.51% 7.58Radio handler 26.87% 12.16% 182.38Radio decode thread 5.48% 2.48% 37.2RFM 66.48% 30.08% 451.17Radio Reception - - 1350Idle - 54.75% -Total 100.00% 100.00% 2028.66

Slide courtesy Jason Hill et al

19

TinyOSTinyOSEvaluation: Diversity in Design and

Usage, Robust Operation

• Diversity in Usage– Created several sample applications that exploit

the modular structure of the system– Source based multi-hop routing applications– Active-badge-like location detection applications– Sensor network monitoring applications

• Diversity in Design– Portability: target multiple CPU architectures– Modularity: accommodate future systems

• Robustness– Compile-time check reduces human error (nesC)– Part of the burden is left to the application

Slide courtesy Jason Hill et al

TinyOSTinyOS

Architectural Implications

• Feedback from TinyOS– Separate microcontroller for each I/O device

• is an option, not a requirement

– Bit-level processing cannot sustain high rates• RadioByte need real non-synthetic hardware • Byte level hardware would save 690 nJ/bit

– Inclusion of hardware support for events• Need for additional set of register • Would save 20µs per event and up to 20% CPU

20

TinyOSTinyOS

Related Works• Real-Time Embedded OSs

– From hand-held to high-end PCs– WinCE, PalmOS, QNX, WxWorks, ... – Cool in principle, far from sensor constraint

• QNX: context switch 2400 cycles @ 33Mhz• VxWorks: 100-1000 Kbytes memory footprint

• Real-Time Executives OSs– Small OS for moto-controller, microwave ovens– Cream, pOSEK, Ariel, ...– Meet only constraint requirement

• Control-centric rather than dataflow centric

TinyOSTinyOS

Conclusions

• TinyOS – highly modular software environment – tailored to the requirements of Sensors Network– power-efficient and concurrency-intensive– able to support new devices as they evolve.

• Running an application on TinyOS– can help reveal the impact of architectural changes – feedback to design hardware that is optimized for a

particular application• Writing an application on TinyOS ?

– Let’s move to nesC