1

TOSSIMTOSSIM

Sensors as SoftwareTOSSIMTOSSIM

Dario Rossidario.rossi@polito.it

TOSSIMTOSSIM

Outline• Motivations • Architecture Overview

– Compiler support– Execution model– Hardware/Radio models– Communication services (TinyViz)

• Evaluation– Bridging, Fidelity, Scalability, Completeness

• Extension– PowerTOSSIM

2

TOSSIMTOSSIM

Sensor Networks & Simulation • Sensor networks…

– Require large scale deployment (smart dusts)– Located in physically inaccessible places

• Apps are deployed…– only once during network life time – Little or no scope to re-deploy on errors

• Early evaluation of the system…– Is an integral part for development steering– Check correctness of application behavior – Sensors are pretty hard to debug

• Failure bug -> easier• Operational but aberrant behavior -> harder

TOSSIMTOSSIM

Debugging a Mote...Used to require hardware modification...

...to the mote(removal of a resistor) ...

...to the board(addition of jtag connector)

3

TOSSIMTOSSIM

Debugging a Mote...still requires another hardware toy...

...in TinyOS authors’ own words: “[...] Prepare to a slightly painful experience”

TOSSIMTOSSIM

Simulation Pros and Cons• Several advantages…

– Study system in totally controlled environment– Explore configuration difficult to construct– Observe interaction difficult to live-capture– Helps in design improvement– Cost effective alternative

• …as well as disadvantages– May not represent accurate real-world results– Depends on several modeling assumptions– Tradeoff details and accuracy for feasibility

4

TOSSIMTOSSIM

Existing Tools?• Not very suitable for sensor networks

– Provides abstraction levels either • too coarse -> packet level (ns-2, Glomosim, …)• too fine-grained -> instruction-level (Atemu,

Proteus,…)– Do not address the complex interactions

• Among motes (Application level)• Within motes (Network stack) • Motes and environment (Real world noise)

– Need to handle 2 parallel implementations• One for the real motes, one for the simulator

• TinyOS common framework for sensor apps

TOSSIMTOSSIM

Key Requirements• Scalability

– How many ?

• Completeness– How much ?

• Fidelity– How similar ?

• Bridging– How easy ?

5

TOSSIMTOSSIM

Key Requirements• Scalability

– Largest real deployment: 850 nodes– Must handle these sizes and above

• Completeness– Cover as many interaction as possible– Simulating complete application is required

• Fidelity– Capture network interaction at a fine grain– Must be able to reveal unanticipated interactions

• Bridging– Bridge the gap between algorithm and implementation– Often, the algorithm is sound but implementation is not

TOSSIMTOSSIM

TOSSIM ArchitectureTOSSIM• Is a discrete-event simulator• Utilizes TinyOS’s component based architecture

•Transparently integrateswith TinyOS

–providing a new hardware resource abstraction layer

–TinyOS event-drivenexecution maps well to a discrete-even simulation

6

TOSSIMTOSSIM

TOSSIM Architecture

TOSSIMTOSSIM

TOSSIM Architecture• Compiler Support• Execution Model• Hardware Emulation• Radio Model• Communication Service

7

TOSSIMTOSSIM

Compiler Support

TOSSIM C

MOTE nesC

Currently running mote

MOTE CComponent frame

TOSSIMTOSSIM

Execution Model• Simple event queue

– Substitute TinyOS scheduler– Interrupts == simulator events– Simulator events != TinyOS events– Interrupts are NOT pre-emptive

• Time unit – Mote clock granularity (4 Mhz)– Delta time (similar to VHDL)

• Events do not take any virtual time to execute• Infinite delta time adds up to zero virtual time

8

TOSSIMTOSSIM

Hardware Emulation• Hardware

– TinyOS abstract hardware as component – TOSSIM emulates hardware components

• ADC, Clock, EEPROM, radio, potentiometer,...• Emulation

– Split-phase operations preserved • Latency taken from real world sensor-boards

– External function provides readings• Constant (changeable at run-time) or random

– Radio chip handled specially• Channel state depends on Radio Model (error is NOT)• Signal is 1 or 0 (interference is OR, worst case)

TOSSIMTOSSIM

Radio Model• Directed graph of bit-error probabilities

– Pros• Flexible, changeable at run-time• Asymmetric links

– Cons• Signal strength not considered• Independent bit errors

– Simple models provided• Error free links (for debugging)• Bit error extrapolated from measured packet loss

rates

x

y

zex,z

ez,x

9

TOSSIMTOSSIM

Communication Service

TinyViz GUI• Vizualization/Actuation• Real/Simulated network• Customizable

Exchange data over TCP/IP• Sim -> App: debug msg, pkts as over UART• App -> Sim: commands, inject pkts, turn

motes on/off

TOSSIMTOSSIM

Communication Service

SerialForwarder

TOSSIM

Communication

Event Bus

GUI Plug-ins

Event/Event/MsgMsgDrawingDrawing

Commands

10

TOSSIMTOSSIM

Evaluation• Scalability

– How many ?

• Completeness– How much ?

• Fidelity– How similar ?

• Bridging– How easy ?

TOSSIMTOSSIM

Evaluation: Scalability

11

TOSSIMTOSSIM

Evaluation: Scalability

BaseBase

RadioRadioSim QueueSim Queue

OtherOther

For instance, 10 simulated secondspkt level = 25 seconds real timebit level > 1 hour real time

Surge

TOSSIMTOSSIM

Evaluation: Completeness• TinyOS Debugging

– Debug TinyOS radio stack• Discovered & fixed problems that were unnoticed

during testbed deployment• Possible thanks to the bit-level granularity

– Debug applications• Discovered & debug the Surge application• Surge requires complex interaction between

components

• TOSSIM is complete enough– But limited to ONE application at a time

12

TOSSIMTOSSIM

Evaluation: Completeness• Surge Application: high loss rate

Send queue often overflows... But why ?

TOSSIMTOSSIM

Evaluation: Completeness• Surge Application: bug fixes

Send queue often overflows... But why ?

1) Duplicate suppression in send queue

2)Break all routing cycles

13

TOSSIMTOSSIM

Evaluation: Fidelity• Fidelity Effort

– Bit granularity– Simulates ADC readings– Simulates interrupts

• Some Imperfections– Does not model radio propagation

• bit-level error abstraction– Interrupts are NOT pre-emptive– Only RFM (mica) and CC1000 (mica2)

networking stack

TOSSIMTOSSIM

Evaluation: Fidelity

( )( )( )( ) ( )( )( )( ) ( )( )( )( )2 ft

1 2 25... ...

Medium power 200 pkts

14

TOSSIMTOSSIM

Evaluation: Bridging • TinyOS core integration

– Instrumented nesC compiler – Transparently compiles application code

• for TOSSIM (make pc)• for specific hardware (make mica2)

– Tested code can be deployed right away

• TinyOS tools integration– Available tools can cooperate with TOSSIM

• TinyViz, SerialForwarder

TOSSIMTOSSIM

Extension: PowerTOSSIM

Goals•Power profiling•CPU profiling•mica2 radio

15

TOSSIMTOSSIM

PowerTOSSIM: Benchmark

•Develop a hardware power model•Isolate the power consumption of different hardware devices

•Microbenchmarks•CPU (different known power levels, instruction count) •Radio (different power levels)•EEPROM (read/write)•Sensing unit

TOSSIMTOSSIM

PowerTOSSIM: Power Model

16

TOSSIMTOSSIM

PowerTOSSIM: Architecture•Add module to track power state•Minor modification to hw components to report transistions •Decouple data gathering from processing

TOSSIMTOSSIM

PowerTOSSIM: Implementation

17

TOSSIMTOSSIM

PowerTOSSIM: ValidationMeasured

CntToLedsAndRfm•Cnt++•putLeds(Cnt & 0x07)•sendPkt(Cnt)

TOSSIMTOSSIM

PowerTOSSIM: ValidationMeasured

CntToLedsAndRfm•Cnt++•putLeds(Cnt & 0x07)•sendPkt(Cnt)

0 2 4 6

18

TOSSIMTOSSIM

PowerTOSSIM: ValidationMeasured Simulated

TOSSIMTOSSIM

PowerTOSSIM: Validation

19

TOSSIMTOSSIM

Conclusion• TOSSIM

– Simulates TinyOS applications– Can be useful during development phase

• TOSSIM is– Integrated into TinyOS

• The same code can be used for simulation and real test-beds

– Extensible • Radio Stack, Power and CPU Profiling

– Scalable… enough– Quite accurate… but not authoritative

• Let’s move to the applications