Jan 31, 2007 CS511 1

UnboundSTEP graph

Bound STEP graph

Resource management components solve graph embedding

Deployment

Sensor eXecution Environments

Remember the SNBench ?

SXE

SXE

SXE

trigger

email

“security@bu.edu”

cam2

snapshot

motion

clock 4AM2AM

< <

&&

SNAFU Program

dispatchlinking

email(“security@bu.edu”, trigger( (motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)))

trigger

email

“security@bu.edu”

cam2

snapshot

motion

clock 4AM2AM

< <

&&

compilation

Jan 31, 2007 CS511 2

STEP: Sensorium Typed Exec Plan

add

LTE5

cond

isnilequals

level_trigger

not

Virtual Instruction Set ArchitectureDirected Acyclic Graph

level_trigger(

not(equals(5,LTE)),

cond(isnil(LTE),

1,

add(LTE,1)

))

LTE

1

LTE 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, 2007 CS511 3

STEP: XML Representation

STEP Graphs are serialized/stored as XML level_trigger( not(equals(5,LTE)), cond(isnil(LTE),1,add(LTE,1)) )

<stepgraph id="prog_count"> <level_trigger id="TriggerHead"> <exp id="not" opcode="sxe.core.not"> <exp id="equals" opcode="sxe.core.equals"> <value id=“stop_value"> <snobject type="snbench/integer">5</snobject> </value> <last_trigger_eval id="lte" target="TriggerHead"/> </exp> </exp> <exp id="cond" opcode="sxe.core.cond"> <exp id="isnil" opcode="sxe.core.isnil"> <last_trigger_eval id="lte1" target="TriggerHead"/> </exp> <value id="start_value"> <snobject type="snbench/integer">1</snobject> </value> <exp id=“add" opcode="sxe.core.math.add"> <last_trigger_eval id="lte2" target="TriggerHead"/> <value id="1"> <snobject type="snbench/integer">1</snobject> </value> </exp> </exp> </level_trigger></stepgraph>

Jan 31, 2007 CS511 4

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, 2007 CS511 5

Project Descriptions

1. STEP Programming GUI/development environment

2. Leveraging the SNBench infrastructure i.e., writing/enabling SNBench apps/services

3. SNAFU to STEP compiler/development environment

Jan 31, 2007 CS511 6

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, 2007 CS511 7

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, 2007 CS511 8

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, 2007 CS511 9

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, 2007 CS511 10

2: 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 email notifications when an image from a camera differed from the initial captured image. To support this the group implemented opcodes to support e-mail, 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, 2007 CS511 11

2: 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 email 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, 2007 CS511 12

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, 2007 CS511 13

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, 2007 CS511 14

Kismet support in SNBench 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, 2007 CS511 15

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, 2007 CS511 16

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, 2007 CS511 17

Example #2

E-mail an administrator on every detected DEAUTHFLOOD

The email 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”), email(“mocean@cs.bu.edu”, concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)) ) )

Jan 31, 2007 CS511 18

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”), email(“mocean@csa.bu.edu”, drawstring( concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)), findAdjacentSensor(“Image”, getField(WIFIALERT,

“BASESTATION”)) ) ) )

Jan 31, 2007 CS511 19

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)) ) ))