html5-img
1 / 16

Simple Monitoring and Action Profile

Stephen Dawson-Haggerty Xiaofan Jiang David Culler. Simple Monitoring and Action Profile. 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

nadda
Download Presentation

Simple Monitoring and Action Profile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Stephen Dawson-Haggerty Xiaofan Jiang David Culler Simple Monitoring and Action Profile

  2. Vision Enable “Apps for the Building” SMAP

  3. 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

  4. 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

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

  6. System Designor, 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! Application Interface HTTP Engine TCP TinyOS/BLIP HYDRO Routing 6lowpan HC 802.15.4 Link

  7. Meter Interface: HTTP + JSON • Use HTTP as app-level control protocol • JSON is concise object transport • Also defined a compressedapplication/x-binaryjson content type • Distinguish metering from sensing • Integrate raw data with metadata • Calibration • Engineering units • Reporting support allows pushing of sensor data Sensor Edge Router Proxy, Database User systems

  8. 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: http://meter1.cs.berkeley.edu/report { "ReportResource" : "/meter/*/reading", "ReportDeliveryLocation" : "http://webs.cs.berkeley.edu/receivereports.php", "Period" : 60, "Minimum" : 50, "Maximum" : 100 }

  9. Example JSON {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime": "second", "MeterType" : "electric" } instance {"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"},...]}} schema

  10. 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

  11. Compression {"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime" : "second", "MeterType" : "electric" } instance 0x21512312 0x10 … 0x3 0x0 0x1 0x0 compressed 1 kW Magic Length Multiplier UnitofMeasure

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

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

  14. 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

  15. 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

  16. Questions

More Related