Tython Simulation Scripting for TinyOS Mike Demmer / Phil Levis NEST Retreat January 2004.

Slides:



Advertisements
Similar presentations
Network II.5 simulator ..
Advertisements

How to use TinyOS Jason Hill Rob Szewczyk Alec Woo David Culler An event based execution environment for Networked Sensors.
TinyOS Tutorial, Part I Phil Levis et al. MobiSys 2003.
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
System Integration and Performance
Categories of I/O Devices
NesC Prepared for the Multimedia Networks Group University of Virginia.
1 Lab 3 Objectives  Case study: “Hello world” program on motes  Write you first program on mote.
Extensibility, Safety and Performance in the SPIN Operating System Presented by Allen Kerr.
Operating System Structure
Overview: Chapter 7  Sensor node platforms must contend with many issues  Energy consumption  Sensing environment  Networking  Real-time constraints.
MotoHawk Training Model-Based Design of Embedded Systems.
TOSSIM A simulator for TinyOS Presented at SenSys 2003 Presented by : Bhavana Presented by : Bhavana 16 th March, 2005.
Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff.
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
SUPERB-IT Center for Hybrid and Embedded Software Systems COLLEGE OF ENGINEERING, UC BERKELEY August 4, 2006 SUPERB-IT.
A Quick Note on TinyOS Chris Merlin Group Meeting January 21 st, 2009.
TOSSIM 17.ix.2001 TOSSIM v01.a. TOSSIM 17.ix.2001 TOSSIM Capabilities Simulates large mote networks under Linux Uses existing TinyOS code (different compilation)
TinyOS Software Engineering Sensor Networks for the Masses.
Matnet – Matlab Network Simulator for TinyOS Alec WooTerence Tong July 31 st, 2002.
WSN Simulation Template for OMNeT++
Chess Review November 21, 2005 Berkeley, CA Edited and presented by Sensor Network Design Akos Ledeczi ISIS, Vanderbilt University.
TOSSIM: Visualizing the Real World Philip Levis, Nelson Lee, Dennis Chi and David Culler UC Berkeley NEST Retreat, January 2003.
QualNet 2014/05/ 尉遲仲涵. Outline Directory Structure QualNet Basic Message & Event QualNet simulation architecture Protocol Model Programming.
OMNET++. Outline Introduction Overview The NED Language Simple Modules.
Sikuli Ivailo Dinkov QA Engineer PhoneX Team Telerik QA Academy.
NetSim ZigBee Simulation Code Walkthrough in 10 steps
Project #2 Mobile Multiplayer Game: Tic-Tac-Toe Project #3 TinyOS Sensing Application EE194WIR Matt Magpayo
Acceleration Based Pedometer
© 2012 LogiGear Corporation. All Rights Reserved Robot framework.
April 15, 2005TinyOS: A Component Based OSPage 1 of 27 TinyOS A Component-Based Operating System for Networked Embedded Systems Tom Bush Graduate College.
Institute of Computer and Communication Network Engineering OFC/NFOEC, 6-10 March 2011, Los Angeles, CA Lessons Learned From Implementing a Path Computation.
Performance of Token- based Distributed Mutual Exclusion Algorithms Scott J. McCallen Kent State University November
Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.
Capture and Replay Often used for regression test development –Tool used to capture interactions with the system under test. –Inputs must be captured;
Magnetic Field Measurement System as Part of a Software Family Jerzy M. Nogiec Joe DiMarco Fermilab.
Support for Debugging Automatically Parallelized Programs Robert Hood Gabriele Jost CSC/MRJ Technology Solutions NASA.
EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Networks – Abdelzaher Tarek,etc An Entity Maintenance and Connection Service.
Oracle Data Integrator Procedures, Advanced Workflows.
Lab 3 Introduction to TinyOS and nesC How to debug programs at PC Examples –Blink Timer –Blink –Hellow World Reference: 1.x/doc/tutorial/lesson1.html.
Simulation of Distributed Application and Protocols using TOSSIM Valliappan Annamalai.
GreenBus Extensions for System-On-Chip Exploration.
NCBI Genome Workbench Chuong Huynh NIH/NLM/NCBI Sao Paulo, Brasil July 15, 2004 Slides from Michael Dicuccio’s Genome Workbench.
The EDGeS project receives Community research funding 1 Porting Applications to the EDGeS Infrastructure A comparison of the available methods, APIs, and.
Main Issues Three major issues that we are concerned with in sensor networks are – Clustering Routing and Security To be considered against the backdrop.
Part A Final Dor Obstbaum Kami Elbaz Advisor: Moshe Porian August 2012 FPGA S ETTING U SING F LASH.
Computer Simulation of Networks ECE/CSC 777: Telecommunications Network Design Fall, 2013, Rudra Dutta.
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
Active Message Application: CONNECT Presented by Xiaozhou David Zhu Oommen Regi July 6, 2001.
Reconfigurable Communication Interface Between FASTER and RTSim Dec0907.
TinyOS Sandeep Gupta. Operating System (OS) What is an OS? Main functions  Process management  Memory management  Resource management Traditional OSs.
1 Software Reliability in Wireless Sensor Networks (WSN) -Xiong Junjie
Source Level Debugging of Parallel Programs Roland Wismüller LRR-TUM, TU München Germany.
Why does it need? [USN] ( 주 ) 한백전자 Background Wireless Sensor Network (WSN)  Relationship between Sensor and WSN Individual sensors are very limited.
Sensor network routing protocol for underground robot remote control Demonstration picture (IDF)
Fermilab Scientific Computing Division Fermi National Accelerator Laboratory, Batavia, Illinois, USA. Off-the-Shelf Hardware and Software DAQ Performance.
TinyOS Sandeep Gupta. TinyOS basics TinyOS is  Single tasking OS  Interrupt driven Written using a Component based language A set of components put.
Tinyos Introduction to Programming Pritee Parwekar.
Interfacing the Internet of a Trillion Things
Simulation of Distributed Application and Protocols using TOSSIM
Data Transport for Online & Offline Processing
In-situ Visualization using VisIt
Northbound API Dan Shmidt | January 2017
Computer Simulation of Networks
extcap – Packet Capture
16: extcap – Packet Capture beyond libpcap/winpcap
ns-3 Waf build system ns-3 Annual Meeting June 2017
Genome Workbench Chuong Huynh NIH/NLM/NCBI New Delhi, India
Single Event Upset Simulation
In Today’s Class.. General Kernel Responsibilities Kernel Organization
Presentation transcript:

Tython Simulation Scripting for TinyOS Mike Demmer / Phil Levis NEST Retreat January 2004

1/14/2004Tython2 Why is simulation important? Motivating example: A first year graduate student in a sensor networks class implementing a simple TDMA slotted ring protocol (guess who) What did I want from simulation? –more manageable code/build/test/debug cycle –richer debugging output – not limited to a few LEDs –ramp up complexity, e.g. start with a perfect radio And more specifically: –move motes in and out of range of each other –fail certain motes to make sure protocol can handle it –test one way radio connectivity –ensure basic correctness while adding more complexity

1/14/2004Tython3 What tools did I have to use? TOSSIM –discrete event simulator for TinyOS applications –same program source that runs on the mote hardware but instead compiled into a simulator executable –bit-level radio model, simulated ADC values TinyViz –framework to visualize and manipulate TOSSIM executions via a Java based application GUI –adds dynamics – can turn motes on/off, affect the radio and sensor models, move motes around, etc. –Java Plugin API to add custom visualizations / manipulations

1/14/2004Tython4 What’s wrong with these tools? Interactivity only through GUI –cumbersome to do a repeated test such as moving motes into and out of range –can’t reproduce operations from run to run, thus hard to isolate differences Extensibility only through Java Plugins –relatively low level API –better suited to extending the TinyViz tool than as a mechanism to enable experimentation No mechanism to access mote state –main source of program output is by adding debug messages to the application source

1/14/2004Tython5 So what’s the solution? Add a scripting framework –integrate Jython – a Java implementation of the Python programming language with object reflection Restructure TinyViz internals into SimDriver –core components to manage interaction such as the radio model, mote location, communication with TOSSIM, etc. –optional GUI for visualization Provide manipulation primitives –Jython object reflection used to expose the SimDriver core –extensible library of Python routines and objects for more complex functionality Add accessibility to mote frame variables –NesC compiler now generates a variable resolution function, accessed via the TOSSIM command interface

1/14/2004Tython6 How do TinyViz / TOSSIM relate? TinyViz GUI NesC events commands TinyVizTOSSIM Mote Application Program Radio Model External Comm Event Bus Plugins SimComm Event Queue

1/14/2004Tython7 How does scripting fit in? ScriptInterpreter simutil Python Classes TinyViz GUI NesC simcore Reflected Classes User Script events commands SimDriverTOSSIM Mote Application Program Radio Model External Comm Event Bus Plugins SimComm Event Queue

1/14/2004Tython8 How about an example… ### ### Periodic Beacon Test Script ### import simcore, simutil, simtime import net.tinyos.message # boot the 10 motes for i in range(0, 9): simcore.motes[i].turnOn() # function to send a new route update message to mote 0 def route_update(event): msg = net.tinyos.message.MyRouteUpdateMsg() simcore.comm.sendRadioMessage(0, simcore.getTosTime(), msg) # set up a repeated call to inject the packet every 10 seconds simutil.Periodic(simtime.onesec * 10, route_update) # run for five minutes, then quit the simulation simutil.CallIn(simtime.onemin * 5, simcore.sim.exit)

1/14/2004Tython9 What’s going on behind the scenes? Jython reflects Java classes to Python –hence the MIG generated MyRouteMessage class The simcore module provides a Python object interface to hide SimDriver / TOSSIM complexities –e.g. sendRadioMessage hides details of creating a TosMSG wrapper and sending a RadioMsgSendCommand to TOSSIM –building blocks for more complex functionality (e.g. simutil ) TOSSIM event queue is the main control loop –all TOSSIM events are sent to the SimDriver and internally distributed via the Event Bus –periodic / future events implemented by inserting an event and registering a callback handler –python scripts can register a handler to get events as well

1/14/2004Tython10 What about mote state variables? When debugging, it’s useful to probe around program state, as is done with gdb Scripts can also use this information –e.g. move a mote randomly until it comes in radio range of another mote, then stop NesC generates a lookup table to resolve component frame variables –translates logical variable name into memory address / size TOSSIM exports resolve/fetch/set commands –reflected through the simcore object interface

1/14/2004Tython11 How does that fit in? ScriptInterpreter simutil Python Classes TinyViz GUI NesC simcore Reflected Classes User Script events commands SimDriverTOSSIM Mote Application Program Radio Model External Comm Event Bus Plugins SimComm Event Queue MoteVariables Variable Resolver

1/14/2004Tython12 One more example… // NesC application source: module NeighborCountM {…} implementation { int count; command result_t StdControl.init() {…} } # Python script: import simcore, simutil, simtime def displaycount(): mote = simcore.motes[0] count = mote.getInt(“NeighborCountM$count”) mote.setLabel(“%d neighbors” % count) simutil.Periodic(simtime.onesec * 5, displaycount)

1/14/2004Tython13 So what does all this let me do? Repeatable simulation dynamics –move motes around, inject radio beacons, etc… –framework to do comparison experiments Automatic parameter exploration –set up a set of scripted tests as a batch job “Adversarial” simulations –force edge conditions such as one way connectivity, failing motes, bogus ADC values, etc. Interactive scripting console for debugging –pause / restart simulation, probe state –can probe a running simulation, attach / detach, etc

1/14/2004Tython14 To wrap up Tython has been checked into the main TinyOS repository, and will be part of the release More information and a simple demo at the poster session later on tonight Questions?

1/14/2004Tython15 Backup Slides

1/14/2004Tython16 Why is simulation important? Sensor Networks programming is hard –distributed, event driven systems, limited output –prototyping, protocol experimentation cumbersome Comparisons of related protocols and algorithms –isolate variability of the environment for “fair” trials Automatic exploration of parameter space –batch simulation execution to tune applications Regression testing

1/14/2004Tython17 How does this callback stuff work? The Periodic and CallIn classes are implemented by: a)registering an event handler with the internal SimEventBus, allocating a unique event identifier b)queuing an event callback in the future by inserting an event on the TOSSIM event queue with the given id c)executing the callback closure if the event’s id matches

1/14/2004Tython18 Huh? How about some code… import simcore import net.tinyos.sim.event class Periodic: def __init__(self, interval, callback): # get a unique event identifier pauseID = simcore.comm.getPauseID() # define an event handler to execute the callback if the id matches def mycallback(event): if (event.get_id() == pauseID): callback(event) simcore.sim.pauseInFuture(event.getTime() + interval, pauseID) # register a handler to get SimulationPausedEvent events evclass = net.tinyos.sim.event.SimulationPausedEvent simcore.interp.addEventHandler(mycallback, evclass) # enqueue the callback after interval seconds now = simcore.sim.getTossimTime() simcore.sim.pauseInFuture(now + interval, pauseID)