SIMPLE MONITORING AND ACTION PROFILE Stephen Dawson-Haggerty Xiaofan Jiang David Culler

Vision Enable “Apps for the Building” SMAP

Reality LOTS of old, new [building, city] sensors LOTS of legacy installed base No lingua franca Let’s support two things: metering and measuring – But let’s do them really well Measuring: instantaneous valuesMetering: accumulated values i.e., temperaturei.e., electricity Units Conversion to Engineering Units Metadata, metadata, metadata

Setting the Scene This is topical: “smart buildings” are here today – 6lowapp – SEP: Zigbee Smart Energy Profile – GreenPlug – Google PowerMeter – CAP: Compact Application Protocol Lots of common requirements – Needs to be miniscule and efficient implementable anywhere – Represent some data simply Can’t do everything for everyone

Design Build JSON/REST/HTTP Interface REST/HTTP – Easily understood JSON – Compact ASCII – Allows validation – Multiple representations possible REST API HTTP/TCP … … JSON Objects

System Design or, REST in 36kB Build on blip, embedded IPv6 stack Use HTTP for control channel Standards in IETF, IEEE moving along nicely, but don’t get held up by them! TinyOS/BLIP HTTP Engine Application Interface Link 6lowpan HC HYDRO Routing TCP

Meter Interface: HTTP + JSON Use HTTP as app-level control protocol JSON is concise object transport – Also defined a compressed application/x-binaryjson content type Distinguish metering from sensing Integrate raw data with metadata – Calibration – Engineering units Reporting support allows pushing of sensor data SensorEdge RouterProxy, DatabaseUser systems

Meter Interface /meter # meters of quantities of flow provide this service [GET] /channelID # a particular channel [GET] /reading # meter reading [GET] /format # calibration and units [GET/POST] /parameter # sampling parameter [GET/POST] /profile # history of readings [GET] /report # create and query periodic reports [GET/POST] POST requests supply JSON objects as arguments: POST: { "ReportResource" : "/meter/*/reading", "ReportDeliveryLocation" : " "Period" : 60, "Minimum" : 50, "Maximum" : 100 }

Example JSON {"UnitofMeasure" : {"type" : "string”, "options":[ {"value":"kW", "label":"kW/kWh"}, {"value":"lph", "label":"Liters per Hour"},...]}, "Multiplier" : {"type" : "integer”, "optional" : "true"}, "Divisor" : {"type" : "integer”, "optional" : "true"}, "UnitofTime" : {"type" : "string", "options": [ {"value":"millisecond"}, {"value":"second"}, {"value":"minute"},...]}, "MeterType" : {"type" : "string", "options": [ {"value":"electric"}, {"value":"gas"}, {"value":"water"},...]}} {"UnitofMeasure" : {"type" : "string”, "options":[ {"value":"kW", "label":"kW/kWh"}, {"value":"lph", "label":"Liters per Hour"},...]}, "Multiplier" : {"type" : "integer”, "optional" : "true"}, "Divisor" : {"type" : "integer”, "optional" : "true"}, "UnitofTime" : {"type" : "string", "options": [ {"value":"millisecond"}, {"value":"second"}, {"value":"minute"},...]}, "MeterType" : {"type" : "string", "options": [ {"value":"electric"}, {"value":"gas"}, {"value":"water"},...]}} {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime": "second", "MeterType" : "electric" } {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime": "second", "MeterType" : "electric" } instance schema

Making it Affordable (for devices on a budget) JSON: Binary transport defined and implemented – Integers to fixed-width types – String enumerations to “c” enumerations HTTP: potentially compressed a la “Chopin” – Defines binary format – Optionally uses UDP transport

Compression application/json94 octets application/binaryjson22 octets {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime" : "second", "MeterType" : "electric" } {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime" : "second", "MeterType" : "electric" } instance 0x x3 UnitofMeasure 0x0 kW 0x0 Multiplier 0x1 1 … … 0x10 Length Magic compressed

Making it Friendly (for web devs) IPv6 / 6LowPAN Wireless Mesh Network ACme Vibration Temperature ACme Humidity Internet Edge Router PAR/TSR Hardware … HTTP API/REST Translation

Making it Friendly (for web devs) HTTP architecture naturally supports proxies – applications don’t need to understand the compression

Implementation 35k embedded TinyOS implementation – Includes IP, TCP, HTTP, SMAP Veris meter gateway – ~30 channel legacy Modbus device Cal ISO gateway – Total system demand is just another sensor! Android application – Uses SMAP backend

Future Work Data, data, and more data! – Make this ubiquitous for all Local sensors – Even port external data sources It’s the apps, stupid! – User portals, live data analysis, anomaly detection – Want to build on top of this substrate Help for legacy – Lossless XML translation – Generic SMAP/XXX gateways: reduces our burden for integrating new data

QUESTIONS