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