sensors as software tossim - · pdf filesensors as software tossim ... still requires...
Post on 05-Mar-2018
227 Views
Preview:
TRANSCRIPT
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
top related