http://www.cs.bu.edu/groups/wing

An Introduction to the Sensor Network WorkBench -- SNBench

Michael Ocean Azer Bestavros & Assaf Kfoury

Computer Science DepartmentBoston University

Jan 24, 2007 CS511 2

Imagine a networked world of ...

... sensors, actuators, processors and storageall part of a shared physical infrastructure

Not separate specialized sensor networks, one common shared, adaptable infrastructure of heterogeneous sensors tasked by novice users

Jan 24, 2007 CS511 3

Deployments not yet materialized

Assistive Environments e.g. for home/hospice/elder care/…

Safety Monitoring e.g. in factories/daycare/hospitals/garages/subway…

Intelligent Spaces e.g. for classrooms/meeting rooms/theaters/farms…

Secure Facilities and Homeland Security Uses e.g. at airports/embassies/prisons/…

People Flow/Activity Studies e.g. at retail stores/museums/…

Jan 24, 2007 CS511 4

Sensorium @ BUA common space equipped with a variety of sensors, actuators and computing elements to detect and respond to activities therein

Infrastructure: Pan-Tilt-Zoom cameras Video sensors 802.11b/g sensors Backend computation Backend TByte storage Berkeley motes

+ Full-time Research Engineer

Jan 24, 2007 CS511 5

Sensor Networks Everywhere?

The hardware is willing, but the spirit is weak. Programming and administration are

tedious Time and expertise are needed to:

program device and role specific code (across heterogeneous devices)

deploy the code onto physical resources schedule and monitor operation

Provide OS-style services to SN applications

Jan 24, 2007 CS511 6

Beyond the Status Quo

Virtual Sensor Networks: A Paradigm Shift Distributed Systems aim to make resource

management/allocation transparent SN applications need explicit negotiation, QoS

management and coordinated arbitration of (sensory) resources

Applications that are event-driven, periodic and spatio-temporal --Not just queries

traditionalSensor

Networks

traditionalDistributed Systems

VSNs

Jan 24, 2007 CS511 8

SNBench:SN Workbench

The Sensorium is the computerThe SNBench provides users with their own Virtual Sensor Network via programming and run-time infrastructure that eases specification and automates deployment of distributed applications onto the physical infrastructure.

What sensors can I use and what functionality do

they expose?

Jan 24, 2007 CS511 9

SNBench: Goals Program and deploy a SN App in minutes

High-level languages abstract away irrelevant details Program the network, not the nodes Each program runs on an SN “slice” (i.e., a VSN)

Painless administration Self-organizing, automated dispatch SN can grow or shrink with resource availability

common run-time & resource management infrastructure

Extensibility Support for new sensing hardware, modalities or

computations require implementing Java interfaces SN programmers continue to use a simple, high-level

language and can immediately leverage new capabilities

Jan 24, 2007 CS511 10

snBench: Programming Cycle

Program Program specified by gluing together building blocks

using SNAFU language Compile

SNAFU program is compiled to produce a plan of execution expressed in STEP

Map and Link STEP plans are decomposed in smaller dispatch-able

STEPs which are linked Load and Execute

STEP plans are dispatched (i.e., loaded) onto a common runtime/execution environments (SXEs)

Jan 24, 2007 CS511 11

UnboundSTEP graph

Bound STEP graph

Resource management components solve graph embedding

Deployment

Sensor eXecution Environments

SNBench: Program Life-cycle

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

Overview of SNAFU

SNAFU: Sensor Network Applications as Functions Functional* specification language

computational dependency and concurrency are explicit

Programs describe a SN data-flow video/audio/scalar data is acquired by sensors data is manipulated by functions

e.g., computation, sensing, communication, storage, decision, repetition

respond with actuators or other actions SNAFU is an interface to (is compiled into) STEP

Functions in SNAFU are “Opcodes” in STEP

Jan 24, 2007 CS511 13

SNAFU: SNet Apps as FUnctions

Functional specification language identify the face seen through camera 1

variable assignment has functional syntax

if-then-else

identify(facefind(get(image,cam1)))

cond(predicate,do-if-true,do-if-false)

let x = get(image,cam1) incond(facefind(x),facecount(x),0)

Jan 24, 2007 CS511 14

Persistence and Iteration

SNAFU does not allow recursion Repetition or persistent computation

achieved through the “trigger” construct event monitoring

Two general types of triggers: Transient – i.e., will expire naturally Persistent – i.e, will run “forever”

Jan 24, 2007 CS511 15

Transient: “wait until” Trigger

Evaluate p until p becomes true then evaluate r Respond to “event” p with “response” r

trigger(p,r)

do {} until (p) ; return (r) ;

After r, evaluation of trigger is completeTime

Tri

gger

P = True

P = False

trigger(greater(roomtemp,”80c”),hvac_heatoff)

Jan 24, 2007 CS511 16

Persistent (1): Level Trigger

Evaluate p until p becomes true then evaluate r --forever

every time p is true re-evaluate r

level_trigger(p,r) while(true)

if (p) return (r);

Level triggers are persistent queries that return a stream of evaluations of “r” while “p” is true

Time

Tri

gger

P = True

P = False

Jan 24, 2007 CS511 17

Persistent (2): Edge Trigger

“On Every First” “When p transitions to true re-evaluate r”

edge_trigger(p,r) while(true) if (p) {return(r); while(p) {}};

Edge triggers are persistent queries that return a stream of evaluations of “r” every time “p” transitions from false to true

Time

Tri

gger

P = True

P = False

Jan 24, 2007 CS511 19

Triggers: Accessing results

persistent triggers values change over time Three trigger “read” semantics:

Non-blocking read - Last result is returned Blocking read - Wait for next result Fresh read - Wait for a “from scratch” result

Tri

gger

P = True

P = False

Time

Non-b

lock

ing

Blo

ckin

g

Fre

sh

Read

Jan 24, 2007 CS511 20

Trigger “recursion”

LAST_TRIGGER_EVAL Allows the body of a trigger to access the

value returned at the “last” evaluation of that trigger i.e., history, state, recursion

Example: the following counts from 1 to 5

level_trigger(

not(equals(5,LTE)),

cond(isnil(LTE),1,add(LTE,1))

)

Jan 24, 2007 CS511 21

SNAFU Primer/Cheat Sheet Iterative computation via trigger construct

no recursion by reference (no cycles in a STEP graph) repeatedly test for event and respond when true

trigger(p,r) “once p is true return r” level_trigger(p,r) “every time p is true return r” edge_trigger(p,r) “every time p transitions to true

return r” LAST_TRIGGER_EVAL is cycle-safe reference to previous trigger

value within trigger predicate or body (simulate recursion)

References leteach A = F in X “each A is expanded to inst of F in X” letconst B = G in Y “B is the constant result of G in Y” letonce C = H in Z “C is an evaluation of H done once per

iteration in Z (Z is a trigger)”

Jan 24, 2007 CS511 22

SNAFU STEP

STEP: Sensorium Task Execution Plan explicit graph of the evaluation strategy

(data flow w/ computation dependency) In evaluation values percolate up the STEP graph

from the leaves Demand for evaluation is pushed down from the root Most nodes require all children to be evaluated before

they may evaluate however there are exceptions: add(a,b,c) requires a,b,c cond(a,b,c) if(a) then (b) else (c) level_trigger(p,r)

Jan 24, 2007 CS511 23

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

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

snBench: Runtime components

Sensor eXecution Environment (SXE) Runtime that executes STEP

Sensorium Resource Manager (SRM) Monitors local-area SXEs, network

Sensorium Service Dispatcher (SSD) Partitions STEPs to fit onto SXEs

SD, SXESXE

SXE

SXE

SXESXE

SXE

SXE, Compiler

Jan 24, 2007 CS511 26

SSD: STEP decomposition

Given the state of the resources in the SN, split the STEP into smaller STEPs to be deployed onto available resources Insert into the sub-STEPs additional nodes

(e.g., network sockets) that allow the sub STEPs to compute the larger STEP

Find a partitioning that minimizes new computation i.e., maximize the reuse of already deployed STEP

nodes [Mapping and linking]

Jan 24, 2007 CS511 27

SSD: Mapping/Linking Resources

SXE

SXE

SXE

trigger

email

“security@bu.edu”

cam2

snapshot

motion

clock 4AM2AM

< <

&&

Jan 24, 2007 CS511 28

SSD: Code Reuse in Mapping

Different programs may share STEP sub-graphs Example:

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

trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)),

snapshot(cam2)), facelibrary(amber.alert.images.boston.gov)), email(lpd@boston.gov, “Amber Alert match!”))

Jan 24, 2007 CS511 29

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

Sensor eXecution Environment

A run-time environmentpresent on most resources in the Sensorium Advertises the node’s

computational/sensing capabilities

An SXE is an abstraction of physical resources, accessible via STEP

Jan 24, 2007 CS511 31

SXE: STEP Interpretor/Evaluator

Accepts STEPs from SSD Maintain STEP nodes’ state, enable data flow Schedule nodes for execution when ready Provide results via HTTP

Jan 24, 2007 CS511 32

SXE: Implementation

Java 1.5 based XML parser, STEP interpreter, web server, XSLT for

HTML interface STEP Functions are Java based, easily added New sensor types require the addition of a new

SensorHandler (Java based) for the SXE detects, communicates with, and reformats data from a

specific device to produce snBench typed data idiosyncrasies of the particular hardware/interface are

abstracted away by SNAFU/STEP Image/Video: Java Media Framework Berkeley motes via wireless gateway Wireless Network Intrusion Detection: Kismet via gateway

Jan 24, 2007 CS511 33

SXEs

What if we can’t run SXE on a node?

STEP: as a virtual ISA Embedded C dialects? Java ME? ASM?

Alternate linking protocols Serial (base station) SN wireless protocols (e.g.

802.15.4)

Jan 24, 2007 CS511 34

Intrinsic Research: Expressive PL

Better Programming Languages Alternate Execution Environments

STEP

SNAFUSnQL SnLOG

SnC

SXEJ2ME

Native CJXTA

Jan 24, 2007 CS511 35

SNBench: Progress Foundation for SNBench is done

basic SNAFU->STEP compiler SXE

Mid-powered computing nodes Sensor integration for:

Video sensing Berkeley Motes (temperature) PTZ image sensors Wireless network intrusion

SSD Basic STEP linking/dispatch Basic SRM

Jan 24, 2007 CS511 36

Future Directions/Work

“Types” Real-Time/QoS Scheduling Confidentiality/Trust

Verification Model checking approach to analyze STEP programs

Basic STEP interpreter in TLA+ Type safety, timing invariants, verify if certain nodes

are executed (in finite time), etc. Generate TRAFFIC gadget specs from STEP programs

Other Programming Languages beside SNAFU Alternate Execution Environments Compile STEP to C ? ASM?

Jan 24, 2007 CS511 37

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

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

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

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

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

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

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