EmTOS An environment that includes mote s (running on TinyOS) and - - PDF document

1

1

EmTOS

A Platform for Simulating Heterogeneous Systems

Presented by

Brian Vacek

2

What is a “Heterogeneous System”?

□ An environment that includes mote s (running on TinyOS) and mic r

• se r

ve r s (more

expensive, high-power, low-distribution servers running on Linux) □ Systems in which motes vary in OS, design, applications or sensor capabilities □ Systems that must test gateways, interfering systems and emerging technologies

3

□

Arial robot suspe nde d from fixe d c a ble .

□

Communic a te s with mobile units be low.

□

Communic a te s with fixe d se nsors be low.

□

De te c ts physic a l

• bsta c le s in e nvir
• nme nt.

□

De te c ts a uditory distor tions in e nvironme nt (e c ho, inte rfe r e nc e , e tc ).

Heterogeneous System Example (1)

NIMS (Networked Infomechanical Systems)

4

Heterogeneous System Example (2)

Inte r na ls 2 mode s of c ommunic a tion

5

Where does EmTOS fit in?

T OSSIM (Designed to emulate or simulate multiple

uniform motes in dynamic arrangements running TinyOS/NesC)

+

E mSim (Designed to simulate high-level

microservers, “real-code” applications, separate process trees and radio communications)

=

E mT OS (Heterogeneous systems simulations)

6

EmTOS and EmStar

E

mSta r is a softwa r e syste m for mic r

• se r

ve r s, simula tor s a nd othe r la r g e pla tforms (it c a n not run on mote s).

E

mSta r is built on L inux a nd suppor ts me mory prote c tion a nd dyna mic host c onfig ur a tion pr

• toc ol (DHCP).

Ca pable of e mulating , running a nd de bug g ing

T inyOS/ Ne sC

Code c a n be wr

itte n for individua l ma c hine s or into c onfig file s a nd run using the “e mrun” c omma nd.

E

mr un he lps to e nsur e tha t ta sks involving multiple inte r de pe nde nc ie s r un in the c or r e c t or de r .

E

xa mple c ode show la te r

2

7

Additional Features

□ Allows mic r

• se r

ve r s to double a s mote s: Emulates

TinyOS/NesC on EmStar services (no need to port or translate mote com protocol) □ Simula te a c tua l RF

c ommunic a tion: Can plug into

a Linux server and open a real RF channel □ Simula te mote s with dyna mic

c ode: Variable behavior and

capabilities each represented

HostMote

8

Simulation Modes

□ Simula tion Mode : Models entire environment behaviorally on an EmTOS server. Each node stores info in a config file: □ E

mula tion Mode : Emulates instances of TinyOS/NesC

in a EmTOS wrapper. □ Re ad Mode : Actual motes/microservers interface with simulation server (through “stubs”) to collect data, visualize, analyze and debug. □ Hybrid Mode : A combination of emulation and real mode.

*L

• c a tion

*Or ie nta tion *Ra dio Cha nne ls *Se nsors *Softwa r e

9

Mode Diagrams:

Ha r dwa r e : Softwa r e :

E mula te d L a ye r > Combina tion < Physic a l Node s Be ha viora l Mode l > Combina tion <

10

EmTOS Unified Visualization

*E

mvie w: A single screen that displays all nodes

(motes and microservers) as well as all connections between nodes and their respectiveconnection qualities. *Information gathered from the simulation and debug stubs generates the image. *New application, services and states can be created using C/GTK. Analysis data can be printed to a log file.

11

Example Visualization

Sink Node L ink line (c ommunic a tion) Conne c tion Qua lity

12

Performance (1)

Clock Jitter

Timer Jitter – Unwanted variation in

signal characteristics (timer)

Observations:

• The real mote has high precision

unless the timer is scheduled late due to computations or other tasks.

• The EmTOS simulation has low

precision (due to the cap on the Linux jiffy clock) but averages correctly.

• While timer accuracy is not highly

affected in practice, scheduling and interruptions are not well simulated.

Ac tua l Mic a 2 E mT OS Sim

3

13

Performance (2)

Packet Latency

Packet Latency – Round trip

time of signal during sample ping.

Observations:

• The HostMote protocol incurred

an overhead of 8 bytes per packet.

• EmTOS incurred an additional

60ms overhead in emulating the necessary hardware processes.

14

Case Study: ESS

□ A live test was performed using 14 ceiling-mounted mica2 motes with sensors in a 50x10m area (see figure in slide 8). □ All four modes were tested for 90 minute runs with each node asked to determine the “best” route to a sink node (with either 1 or 2 sinks available)

Re sults:

• Emulation and Simulation performed faster than

was actually observed in practice.

• Increasing the number of sink points, only

marginally improves shortest path! Are glitches part

• f ESS or EmTOS?

15

Graphed Results from ESS Test

Note tha t Simula tion a nd E mula tion Mode pe rfor m similarly and that Hybr id and Re a l Mode pe rform simila rly (a s would be e xpe c te d).

16

Critiques

□

Re la tive ly unte ste d

(active user base ~100) □

Sc a r c e doc ume nta tion

(Tutorial site still under production) □

L imite d sc ale

(performance limited to <500 nodes) □

L imite d Support (yet to

make compatible with SOS and some others) □

Ina c c ura te T ime r(by an

• rder of magnitude)

□

Sing le vs multi- thr e a de d syste ms inc onsistanc ie s

(simulated motes can disobey interrupt rules) □

Pa ra lle l simula tions not ye t possible

□

Obje c t inte rfe re nc e not fully supporte d

(simulated obstacles do not affect the network realistically) □

De bug g ing re a da bility

(one large log file)

17

Comparison to TOSSIM

□ EmTOS has many advantages in terms of flexibility and adaptability for complicated situations that require a variety of sensor types or functions. □ EmTOS interface better with higher-level devices like microservers or gateways. □ TOSSIM still performs better in networks requiring large dense distributions of uniforms motes. □ TOSSIM has higher reliability and data realism (within its limited scope). □ TOSSIM is clearer and more accurate with error detection and reporting.

18

Code Sample

# Builds TinyOS executable from within an EmStar build file build tos { target CntToLedsAndRfm { tinyos-1.x/apps/CntToLedsAndRfm } } # -*- Mode: C -*- # Cnt.run # Emruntab that runs CountToLedsAndRfm in EmTOS include mote/mote.run &mote_hostmote(/dev/ttyS0,mica2,0); &mote_motenic(mote0,0,show="leds"); # Wires to Transceiver process CntTLaR { type = daemon; waitfor = mote0; cmd = "mote/CntToLedsAndRfm"; # Runs LED application } Code c a n be wr itte n in Ne sC a nd e mula te d or wr itte n in the E msta r fr a me wor k.

4

19

Questions or Comments

□ Are heterogeneous systems clearly the way of the future? Would added cost endanger EmTOS? □ What is TOSSIMs solution to heterogeneous systems? Does EmTOS have other potential rivals? □ How can the visual interface or debugging files be made most clear and useful? □ What are some practical uses for EmTOS? Where would it be impractical? □ Do you think there is a target mote:microserver ratio that is most efficient? □ Can EmTOS be used to simulate mobile agents?

20

References

□

• L. Girod, T. Stathopoulos, N. Ramanathan, J. Elson, D. Estrin, E. Osterweil, and T.

Schoellhammer, A System for Simulation, Emulation, and Deployment of Heterogeneous Sensor Networks, ACM Conference on Embedded Networked Sensor Systems (SenSys), November 2004. (All images except NIMS came from the above article) □

• P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: Accurate and Scalable

Simulation of Entire TinyOS Applications, ACM Conference on Embedded Networked Sensor Systems (SenSys), November 2003. □ http://research.cens.ucla.edu/projects/2006/Systems_Infrastructure/Emstar/de fault.htm □ http://cvs.cens.ucla.edu/emstar/tut/samples/index.html (code sample) □ http://research.cens.ucla.edu/portal/page?_pageid=56,48345,56_48347&_da d=portal&_schema=PORTAL (NIMS image)