Service-Based Universal Application Interface for Demand Response Energy Systems (UC Berkeley Project)

Goal: Develop and demonstrate an application development environment for a scalable and extendible demand response system Funding: $250 K Period of Performance: 4/15/2005 – 4/14/2006 Multi-disciplinary Collaboration Team: Jan Rabaey: EECS Paul Wright: Mech. Eng. Dept. Ed Arens: Architecture David Auslander: Mech. Eng. David Culler: EECS 5 Graduate Student Researchers

1 The Demand Response Scenario and the Energy-Cost Aware Home

Utility Temperature sensors Power

Price y sensor it c ri Indicator t c Power e le ic ed r E s actuators P u Real- time Meter

Distributed network of wireless sensors, actuators and controllers: Occupancy • enable deployment of DR in sensors residential settings

• lead to substantial reduction2 in energy cost The Big Picture

Major Challenge: Proliferation of hardware and software options Ease of application development Ease of deployment Ease of maintenance Our Proposed Solution: A Universal Application Interface for ad-hoc wireless sensor and actuator networks Based on library of universal services Called SNSP (sensor network service platform) Project Goal: Demonstrate Portability of DR application over range of implementation platforms Ad-hoc extensibility of functionality

3 Execution Plan

#1. DR Requirement Analysis #2. DR on MICA Nodes using SNSP abstraction. #3. Port DR on Telos Nodes using SNSP abstraction #4. Extended DR application on Mica, Telos and Infineon nodes

4 A Crucial Challenge Ensuring portability, scalability and true ad-hoc deployment A plethora of implementation strategies emerging, some of them being translated into standards

TinyOS/TinyDB

SELECT temp FROM sensors WHERE temp > thresh TRIGGER ACTION SndPkt EPOCH DURATION 5 s

• Bottom-up definition without perspective on interoperability and portability

• Little reflection on how this translates into applications 5 How sensor networks are currently programmed

… (node per node)

NesC NesC middleware lib

Cross-compiler

Platform Operation-system dependent specific Network aware Hardware aware Node aware Hard-coded

6 Example: The DR Scenario

Mote Processor 1. TempNode Data Note: Mote also controls Handles 3-sets 2. Slider Bar Position LED traffic lights of Data 3. 15-min Price update (note: for demo 1-min price signal) For user interface

Fan Control TAVE > TSET: Fan On PG&E Algorithm: TAVE < TSET: Fan On Flashing red Station For system 802.11b XML Operational, but … failure terminal

Daily• fixed Price Data scenario (Emergency Data Upload) 15 min • dedicated map of functions to nodes Price Price Mote Mote Mote Update • hardPG&E to extendSignal Radio Processor Radio Power Thermostat 802.11b Mote c S • inter-networkingMeter Ack hard and hardwiredont end Fan Radio r PC104 Signal Reset ol sign Processor Signal al

Temp Mote Signal Sends & Receives Radio CAL Control signals ISO With PG&E station 12345 Tiny TempNode TempNodes send temp Vibration data to thermostat 7 powered Platform-Independent Programming

Application Application Application App 2 App 1 Application …

SNSP

Service PicoRadio ? layer Dust? Telos ?

• Service layer abstracts hardware and networking from application programmer • Currently made available as set of TinyServices on top of TinyOS

8 A Functional View of DR

Sensors Actuators Energy sensors Temp Sensors Traffic lights Two controllers: Thermostat + price monitor

User inputs Fans and AC (sliders, …)

Displays Price Sensor(s) CAL Determine what and when to turn on/off ISO based on readings from sensors and do this using actuators Weather Predicting Sensor(s) Pricing Could be anywhere CAL WWW ISO

Virtual sensors Virtual actuators 9 The Sensor Network as a Distributed Database The query as the basic access mechanism “Get the temperature in the kitchen”

Application Controller

Application Interface SNSP

Query Service (QS) QS allows a controller to S2 obtain the state of a group of components

Application Augmented with a command mechanism Controller “Close the blinds in the living room” Application Interface SNSP

A1 Command Service (CS) CS allows a controller to set the state of a group of A2 components 10 “read temperature in the kitchen” kitchen Using Semantic C Addressing

Name = attribute + scope (temperature:kitchen)

Names are not unique

Names may change during network operation

Enables ad-hoc operation and provides robustness 11 A Programming Abstraction

Platform User SDK independent

Service User App + Service lib Middleware (“TinyServices”)

Compiler Platform specific

12 Pseudo-code Control

Cooling Control Price Display Control Global temp; Global price; ACCntl(short id, short rate){ PriceDisplayCntl(short id){ sensorRequestQuery(kitchen, sensorRequestQuery(PG&E, TempSense.samplerate = rate); PriceSense, ); ...... //receive results //receive results sensorResponse(temp); sensorResponse(price); if temp > 70 act = ON; actuatorRequestCommand(LR, else PriceDisp.price = price); act = OFF; } actuatorRequestCommand(kitchen, ACCntl.activate = act); }

These functions are capabilities & can be re-used

13 tinyServices

User Interface Initiating application: • Request • Result Responding application • Invoke • Response Concept Repository

Middleware: Manages queries/commands Interfaces with routing & app Keeps track of repository

14 tinyServices User Interface

Interface for application to access capability

Interface for capability to respond

Invoke Request “Heat On” “Heat On”

Thermo Heater stat SNSP Actuator Control App App

Result Response “Success” “Success”

15 Auxiliary Services provide Sense of Space, Time and Concept

Location service Time synchronization service

“heat bathroom at 7am”

Concept

C repository service

“bathroom ≡ (x1,y1), (x2,y2)” CRS maintains a (distributed) repository of capabilities of the network and meta-objects

16 Example (from X11 environment)

17 Concept Repository: Enabling true ad-hoc deployment

Goals:

Avoid large set-up efforts, eases parameterization

Introduce meta-concepts such as “kitchen” and “dawn”

Enable dynamic extension of functionality

E.g. Addition of humidity sensors

Present up-to-date overview of network capabilities

18 Sensors Repository Rep

Temperature Sensor Price Sensor Primitive Temperature Price Concept Capability Capability Name TempSense PriceSense Inputs Name: SampleRate -- Type: Short Outputs Name: Temperature Name: Price Type: Short Type: Short Descript Name: Units Descript Name: Max Descript Val: Celsius Descript Val: 1 Descriptors Name: manufacturer Value: Honeywell -- Type: string 19 tinyService Middleware

• Middleware provides 3 functionalities

Repository SNSP Constraint (service discovery (query and satisfaction & concept storage) command)

Physical Modified Normal network publish/subscribe publish/subscribe design

20 Status

Implemented First-Order Version of TinyServices Demonstrated DR application on MICA

Next: Porting to other platforms Full implementation of Concept Repository and other supporting services (location, time) Demonstration of functional extensibility