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 S1 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 21.