TOSSIM : The TinyOS Simulator

Transcript

Dario Rossi, Politecnico di Torino
WSN: THE TOSSIM SIMULATOR
6-8 june 2006
Dario Rossi
Politecnico di Torino
[email protected]
Wireless Sensor Network
Copyright – Tutti i diritti riservati
1
Copyright
• Questo insieme di trasparenze (detto nel seguito slides) è protetto dalle leggi sul copyright e dalle disposizioni dei
trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine,
fotografia, animazione, video, audio, musica e testo) sono di proprietà degli autori indicati a pag. 1.
• Le slides possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti
al Ministero della Pubblica Istruzione e al Ministero dell’Università e Ricerca Scientifica e Tecnologica, per scopi
istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione.
• Ogni altra utilizzazione o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su
reti di calcolatori e stampate) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da
parte degli autori.
• L’informazione contenuta in queste slides è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per
scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è
soggetta a cambiamenti senza preavviso. Gli autori non assumono alcuna responsabilità per il contenuto di queste
slides (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento
dell’informazione).
• In ogni caso non può essere dichiarata conformità all’informazione contenuta in queste slides.
• In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata anche in utilizzi parziali.
2
Outline
Motivations
Architecture Overview
• Compiler support
• Execution model
• Hardware/Radio models
• Communication services (TinyViz)
Evaluation
• Bridging, Fidelity, Scalability, Completeness
Extension
• PowerTOSSIM
3
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
4
Debugging a Mote...
Used to require hardware modification...
...to the mote
(removal of a
resistor) ...
...to the board
(addition of jtag
connector)
5
Debugging a Mote
...still requires another hardware toy
...in TinyOS authors’ own words:
“Prepare to a slightly painful experience”
N. Ramanathan, K. Chang, R. Kapur, L. Girod, E. Kohler, and D. Estrin
Sympathy for the Sensor Network Debugger In Proc. of SenSys 2005.
6
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
And disadvantages as well
• May not represent accurate real-world results
• Depends on several modeling assumptions
• Tradeoff details and accuracy for feasibility
7
Existing Tools?
Not very suitable for sensor networks
• Provides abstraction levels either
– too coarse -> packet level (ns-2, omnet++, 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
Need for simulator tightly bound to TinyOS
8
Key Requirements
Scalability
• How many ?
Completeness
• How much ?
Fidelity
• How similar ?
Bridging
• How easy ?
9
Key Requirements
Scalability
• Largest real deployment: 850 nodes (20,000 secreted)
• 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, algorithm is sound but implementation is not
10
TOSSIM Architecture
•Discrete-event simulator
•Utilizes TinyOS’s component based architecture
•Transparently integrated
within TinyOS
–providing a new hardware
resource abstraction layer
–TinyOS event-driven
execution maps well to a
discrete-even simulation
11
TOSSIM Architecture
12
TOSSIM Architecture
Architectual points
•Compiler Support
•Execution Model
•Hardware Emulation
•Radio Model
•Communication Service
13
Compiler Support
MOTE nesC
Component frame
MOTE C
Currently running mote
TOSSIM C
14
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
15
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)
16
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
x
ex,z
ez,x z
y
–Error free links (for debugging)
–Bit error extrapolated from measured packet loss rates
17
Communication Service
Exchange data over TCP/IP
• Sim -> App: debug msg, pkts as over UART
• App -> Sim: commands, inject pkts, turn
motes on/off
TinyViz GUI
• Vizualization/Actuation
• Real/Simulated network
• Customizable
18
Communication Service
Plug-ins
GUI
Event Bus
Communication
Drawing
SerialForwarder
Event/Msg
TOSSIM
19
Commands
Evaluation
Scalability
• How many ?
Completeness
• How much ?
Fidelity
• How similar ?
Bridging
• How easy ?
20
Evaluation: Scalability
21
Evaluation: Scalability
Surge
Sim Queue
Other
Radio
Base
For instance, 10 simulated seconds
pkt level = 25 seconds real time
bit level > 1 hour real time
22
Evaluation: Completeness
TOSSIM is complete enough
• But limited to ONE application at a time
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
23
Surge Application: high loss rate
Send queue often
overflows... But why ?
24
Surge Application: bug fixes
1) Duplicate suppression
in send queue
2) Break all routing cycles
Send queue often
overflows... But why ?
25
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 stacks
26
Evaluation: Fidelity
)
)
)
)
)
)
(
(
(
(
( Medium power (
1
2 ft
...
2
200 pkts
27
...
25
Evaluation: Bridging
TinyOS core integration
• Instrumented nesC compiler
• Transparently compiles application code
(make pc)
(make mica2)
–for TOSSIM
–for specific hardware
• Tested code can be deployed right away
TinyOS tools integration
• Available tools can cooperate with TOSSIM
–TinyViz, SerialForwarder
28
Extension: PowerTOSSIM
Goals
•Power profiling
•CPU profiling
•MICA2 radio
29
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
30
PowerTOSSIM: Power Model
31
PowerTOSSIM: Architecture
•Add module to
track power state
•Minor modification
required to synth.
hw. components
•Decouple data
gathering from
processing (Python)
32
PowerTOSSIM: Implementation
33
PowerTOSSIM: Validation
Measured
CntToLedsAndRfm
•Cnt++
•putLeds(Cnt & 0x07)
•sendPkt(Cnt)
0
34
2
4
6
Simulated
Measured
35
36
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.
– Extension may be however tricky
• Scalable enough
– But possibly very slow
• Results are quite accurate
– But not authoritative
37
References
•.Levis, N. Lee, M. Welsh and D. Culler, TOSSIM: Accurate and
Scalable Simulation of Entire TinyOS Applications, In Proc. of
SenSys 2003.
V Shnayder, M Hempstead, B Chen, GW Allen, M Welsh,
Simulating the power consumption of large-scale sensor network
applications. In Proc. of SenSys 2004
38

TOSSIM : The TinyOS Simulator

Transcript

Documenti analoghi

Rubâiyât di Omar Khayyâm secondo la lezione di edoardo FitzGerald

Istituto Superiore Mario Boella (ISMB)

Meeting with Magneti Marelli PowerTrain 16 Giugno 14.30, Aula di

PUBLIC AFFAIR

Offerta valida per gli studenti ed i dipendenti del Politecnico di Milano

Social network - Club Mondiale della Formazione

atm garibaldi Milano_ITA

Artiscan - Tecnologie Avanzate

Finale 2008 - [Ave Maria Gounod Soprano

Finale 2007b - [Toccata seconda arpeggiata.MUS]