Jan 31, 2007CS5111 Unbound STEP graph Bound STEP graph Resource management components solve graph embedding Deployment Sensor eXecution Environments Remember the SN Bench ? SXE trigger cam2 snapshot motion clock4AM 2AM << && SNAFU Program dispatch linking trigger( (motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger cam2 snapshot motion clock4AM2AM << && compilation

Jan 31, 2007CS5112 STEP: Sensorium Typed Exec Plan add LTE 5 cond isnilequals level_trigger not Virtual Instruction Set Architecture Directed Acyclic Graph level_trigger( not(equals(5,LTE)), cond(isnil(LTE), 1, add(LTE,1) )) LTE 1 1  STEP is an XML representation of this DAG  let nodes don’t exist  indicate edges point to the same node Recursion is disallowed, one must be careful!  LAST_TRIGGER_EVAL is like a “cycle-safe” cycle...

Jan 31, 2007CS5113 STEP: XML Representation STEP Graphs are serialized/stored as XML level_trigger( not(equals(5,LTE)), cond(isnil(LTE),1,add(LTE,1)) ) 5 1 1

Jan 31, 2007CS5114 Dispatching Tasks onto Resources  Bound STEP nodes are annotated with the resources they are to be deployed on Sockets are added to reconnect flow of computation across physical resources

Jan 31, 2007CS5115 Project Descriptions 1. STEP Programming GUI/development environment 2. Leveraging the SN Bench infrastructure  i.e., writing/enabling SN Bench apps/services 3. SNAFU to STEP compiler/development environment

Jan 31, 2007CS5116 1: STEP Programming GUI/IDE  SNAFU is an accessible high-level prototype programming language that is compiled into STEP – this compiler is in disrepair STEP changes faster than SNAFU STEP is human readable I compose programs directly in STEP using a regular text editor  An argument for a GUI Mistakes in the XML can happen  To verify, I check the picture --e.g., StepIllustrator STEP is a direct representation of the AST  Maps easily into a graphical programming interface Even when SNAFU is up-to-date, some may be confused by a functional programming model (yet have no problem with w/ a graphical programming model) Plus, it looks good in demos and there’s always use for a STEP visualization library

Jan 31, 2007CS5117 1: STEP Programming GUI/IDE  create a graphical programming interface for generating STEP programs allow the user to specify program execution load/save as a properly formatted STEP file (XML) interface should prevent the construction of non- sense or illegal STEP programs  complexity of such a tool may vary greatly –e.g., there are a variety of non-sense programs extensible palette of functionalities  a complete list of valid STEP nodes including sample programs are included in the appendix  new node types may be added  Specific opcodes (instances of ExpNodes) will be added address this via some easily editable configuration files or by reading opcodes from the (possibly augmented) source code directly.

Jan 31, 2007CS5118 1: STEP Programming GUI/IDE  Advice: Reuse existing STEP data structures, parser, error checking, as much as possible  doing so will… save you time/effort allowing you to work on more challenging things ensure that your work can be easily integrated back into the code-base a completely stand-alone solution may not be what we had in mind… This project requires that your group understand the STEP language's syntax and semantics  Don’t proceed unless you understand, and if you don’t ask! A good submission last semester missed a Your group should create a stable, usable interface before worrying about adding "cool" features.  Look at the project submissions from the previous semester (project 3, then) and may consider using them as a basis… Flexibility is very important  If it is difficult to change your editor, it will be difficult to keep it in synch with STEP if there are changes.

Jan 31, 2007CS5119 2: Leveraging the snBench  The snBench is envisioned to help support research that occurs both within and on top of it This project the latter In effect; use the snBench to make interesting/useful applications in the sensor network domain What would/could you/users do (want to do) with an embedded sensor network?  This will certainly require creating new Opcodes to enable new functionalities  Possibly this work may require the creation of new snTypes or support for new sensing hardware e.g., AudioSensor

Jan 31, 2007CS : Leveraging the snBench  Create new interesting sensing domain programs that run on the snBench last semester a group worked on an image-based security system that sent notifications when an image from a camera differed from the initial captured image.  To support this the group implemented opcodes to support , image differencing, and an ad-hoc shared sensor hash table.  Some of this work (with and without modification) has been adopted into the code- base and is available to you this semester Other examples of "interesting" STEP programs that have been implemented include  placing time-lapse images into a database  taking an image of a region in which a wi-fi anomaly is detected  taking an image of a region in which a temperature sensor reading exceeds some threshold Some example opcode extensions might inspire interesting STEP programs example: Image manipulation ops to approximate the number of people in a given frame (via detecting faces, connected blobs, color thresholding, motion, whatever) could enable services such as: count the number of people in a physically warm region of the lab try to observe a correlation between temperature and blobs use blob/motion detection on one camera to reposition other PTZ cameras for a "better shot".  "audio sensors” or audio “actuators” (generate sounds or text-to-speech) or … ?

Jan 31, 2007CS : Leveraging the snBench  In general this involves 1. planning useful or interesting applications/services to run in a sensing, distributed or reactive environment 2. writing these programs in STEP 3. filling in any missing capabilities you might require by extending the opcodes by providing classes for the sxe/core library, sensors, types, etc.  Also… You may wish to your ideas to us before proceeding You are free to make use of the wireless network sensors, temperature sensors, pan-tilt-zoom camera network, local cameras, SQL server or other sensing/computing resources in the lab by "reservation". Documentation is on the web for adding Opcodes, SensorDetectors and more

Jan 31, 2007CS51112 Project 3: SNAFU compiler  The shortage of developers on the snBench has led to the SNAFU compiler to falling behind the the STEP language  Your group clearly must understand the syntax and semantics of STEP to proceed.  For this project, you may use any language you wish. If you use Java, the "Jacc" Lex/Yacc port is highly recommended.  The range of submissions is quite wide are you going to support all of SNAFU? a simple translator with limited error reporting a complete compiler with error reporting based on a real grammar parser a context aware development environment that supports color keywords, auto-completion, etc.

Jan 31, 2007CS51113 Our Experiment Environment Linksys WRT54GL Access Points imaged w/ OpenWRT Axis Pan-Tilt-Zoom Cameras on dedicated gigabit LAN motes, servers, compute node, 750GB SQL server, etc.

Jan 31, 2007CS51114 Kismet support in SN Bench  Each OpenWRT AP runs a Kismet drone and connects to a separate Kismet Server process required to distinguish where events were detected also reduces impact if a Kismet server hangs/crashes  KismetHandler on SXE UDP client to Kismet Server  an SXE is configured to host a KismetSensor by the presence of a local (or remote) configuration file that specifies remote sensors (e.g., KismetSensor via UDP)  state of the “KismetSensor” is inferred by the Handler from the state of the communication link  translator between the published, non-standard Kismet Server protocol and well-typed KismetMessage objects (tagged XML, incl. local timestamp and sensor source)

Jan 31, 2007CS51115 KismetMessage  KismetMessage is a subtype of snStruct Tagged fields correspond to fields in Kismet events New Opcode to read the data produced by KismetSensors (via KismetHandler) For example the SNAFU function: get(“WIFI-alert”, “w02”)  is compiled into a call to Java-based STEP Opcode sxe.core.wifi.get where the sensor parameter is a KismetSensor with ID “w02” (resolved by the run-time infrastructure) and returns a KismetMessage (event) reading the fields from KismetMessages is done using existing snStruct Opcodes getField()  sxe.core.struct.get()

Jan 31, 2007CS51116 WNID in SNAFU – Example #1  Log every detected wireless alert/infraction into a SQL table Unlike the logging provided by Kismet, this program records which sensor has detected the event and logs events into a central log backed by an SQL table (rather than a flat file) The table is keyed by MAC address and includes entries for each detected violation containing a timestamp, the base station where the violation was detected, the type of violation and the signal strength observed by the base station. letonce WIFIALERT = get(“WIFI-alert”, “ALL”) in letonce SRC = getField(“BSSID”,WIFIALERT) in level_trigger( not(isNull(WIFIALERT)), sqlAppend(“SSIDBLACKLIST”, SRC, “PACKET”,WIFIALERT) )

Jan 31, 2007CS51117 Example #2  an administrator on every detected DEAUTHFLOOD The operation could be replaced with any number of response mechanisms including for example, sending an explicit de-authorization to that MAC address. letonce WIFIALERT = get(“WIFI-alert”, “ALL”) in letonce SRC = getField(“BSSID”,WIFIALERT) in level_trigger( equals(getField(“TYPE”,WIFIALERT),“DEAUTHFLOOD”), concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)) )

Jan 31, 2007CS51118 Example #3  Take a picture of a region when an alert is detected The Opcode findAdjacentSensor assumes a well configured deployment environment in which a central SQL database has a mapping of sensor names to other adjacent sensor names Something better next… letonce WIFIALERT = get(“WIFI-alert”, “ALL”) in letonce SRC = getField(“BSSID”,WIFIALERT) in level_trigger( equals(getField(“TYPE”,WIFIALERT),“DEAUTHFLOOD”), drawstring( concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)), findAdjacentSensor(“Image”, getField(WIFIALERT, “BASESTATION”)) )

Jan 31, 2007CS51119 Example #4  Visually track a user by detections of their MAC address PTZImageCaputre drives PTZ network to best capture a particular point in space, w/ that point being the centroid overlap region of the signals detected (yes, we could use other location estimates) listmerge takes results from every responder, not just first define LogImagesOfUser(name,locale) as letconst mac = getMacAddrFor(name) in letonce img = GetImageOfMac(mac,locale) in level_trigger( notnull(img), sqlAppend(“ImageLog”,username,img)) define GetImageOfMac(mac,locale) as PTZImgCapture( ComputeCentroid( ComputeOverlapRegion( listmerge(get(“WIFI-comm”,locale)) ) ))