SIMPLE MONITORING AND ACTION PROFILE Stephen Dawson-Haggerty Xiaofan Jiang David Culler.
-
date post
20-Jan-2016 -
Category
Documents
-
view
216 -
download
0
Transcript of SIMPLE MONITORING AND ACTION PROFILE Stephen Dawson-Haggerty Xiaofan Jiang David Culler.
SIMPLE MONITORING AND ACTION PROFILE
Stephen Dawson-HaggertyXiaofan JiangDavid Culler
Vision
Enable “Apps for the Building”
Panel 1 Panel 2
A
B
A
B
Panel 1 Panel 2
A
B
A
B
1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
A1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
A2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
B2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
B
1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
A1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
1
5
9
13
17
21
25
29
33
37
41
3
7
11
15
19
23
27
31
35
39
A2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
B2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
2
6
10
14
18
22
26
30
34
38
42
4
8
12
16
20
24
28
32
36
40
B
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 values Metering: accumulated values
i.e., temperature i.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 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!
TinyOS/BLIP
HTTP Engine
Application Interface
802.15.4 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
Sensor Edge Router Proxy, Database User 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: http://meter1.cs.berkeley.edu/report { "ReportResource" : "/meter/*/reading", "ReportDeliveryLocation" :
"http://webs.cs.berkeley.edu/receivereports.php", "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" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime": "second", "MeterType" : "electric" }
inst
ance
sche
ma
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/json 94 octets
application/binaryjson 22 octets
{"UnitofMeasure" : "kW", "Multiplier" : 1, "Divisor" : 1, "UnitofTime" : "second", "MeterType" : "electric" }
inst
ance
0x21512312 0x3
UnitofMeasure
0x0
kW
0x0
Multiplier
0x11
…0x10
Length
Magic
com
pres
sed
Making it Friendly(for web devs)
IPv6 / 6LowPANWireless Mesh Network
ACme
Vibration
Temperature
ACme
ACme
HumidityInternet
Edge Router
PAR/TSR
Hardware
…
HTTP
API/REST 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