Non-Intrusive Demand Response Verification

Non-Intrusive Demand Response Verification David Bergman, Kevin Jin, Joshua Juen, Naoki TanakaCS563 – Fall 2009

Background • Overview • On-board Algorithms • Back-end Algorithms • Results and Conclusions 2

Heater Heater Dishwasher Oven Non-Intrusive Load Monitoring (NILM) 3

Consumer Smart Grid Architecture customer web portal utility web portal AMI headend billing system Internet customer network pricing display smartphone smart meter DR gateway PC pool pump plugin hybrid solar panels fridge HVAC From Andrew Wright’s Smart Grid Neutrality Presentation 4

Proposed Monitoring Scheme customer web portal utility web portal AMI headend billing system Internet load shed request verification customer network pricing display smartphone smart meter DR gateway PC pool pump plugin hybrid solar panels fridge HVAC From Andrew Wright’s Smart Grid Neutrality Presentation 6

So… NILM On the Meter? • Unfortunately, we can’t put NILM directly on the meter • Meters have limited computational capacity • Hard to do firmware upgrades • Put NILM on the back-end instead • ZigBee Bandwidth considerations • Fully capable back-end systems

Monitoring Phase 8

Issues With Monitoring • We need an accurate state table for the household • But we cannot simply ask the consumer which appliances are there • And we need to detect when appliances are added or removed …. Therefore, we need to learn, without supervised training, what appliances are actually in the house 9

Learning Control Scheme 10

Learning Phase 11

Only real power being supplied Finite State Machines to group states into appliances Incorrect state table on the meter Error detection and relearning phase Privacy concerns Only respond to demand requests during monitoring Learning can be done in batches and encrypted Integrity concerns Do not have to communicate with appliances directly Problems Our Scheme Addresses 12

Meter Architecture Design • Learning Phase Real-Time Load Data → Edge Detection (Edge Events)→ Headend (state table) → Meter • Monitoring Phase Real-Time Load Data → Edge Detection (Edge Events)→ Appliance Detection (updated states) → State Table (error states) → Relearning Phase 14

Edge Detection Module Goal: Detect abrupt changes in powers reading and output “edge events” Source Edge Detection Algorithm SEL734 Above Threshold Edge Events TED1000 Step Average TED5000 15

Edge Detection Module Step Average • Better compression • Not sensitive to transient events Above Threshold • Less state, fast • Capture spikes Power (W) Time (s) 16

Appliance Detection Module • Goal • Identifying the states of appliances listed in the state table in real-time • Detecting state table error • Inputs • Edge events from edge detection module • State table from AMI head end 17

Appliance Detection Module Edge Events Appliance Detection Edge Events Appliance Profiles Update Relearning Request State Table Load Shedding Request AMI Head End Load Shedding Response 18

Appliance Detection Algorithm • Knapsack Algorithm • Optimal combination of appliances given current load • Running continuously (e.g. 3 times per second*) • Incremental Analysis • Set of appliances changing states at edge event • Running on edge events • Error propagation * Michael LeMay, Jason J. Haas, and Carl A. Gunter. “Collaborative Recommender Systems for Building Automation”, IEEE Hawaii International Conference on System Sciences (HICSS 09),Waikola, Hawaii, January 2009. 19

Appliance Detection Algorithm • Knapsack algorithm on Edge Events • Problem formularization as 0-1 knapsack problem 20

Appliance Detection Pseudo Code and Complexity Analysis For total n states: • A brute force approach: O(2n) • Our approach: O(n(W+T)/M) W+T: total weight M: minimum detection power unit E.g. 10 appliances with 2 states each n = 20, W = 5000W, T = 500W, M=100W O(220) vs O(20*55) Reference: Dr. Steve Goddard, Dynamic programming, Knapsack problem http://www.cse.unl.edu/~goddard/Courses/CSCE310J 21

Example Edge detected: 12/2/2009 6:07:18 Observed Real Power = 73 (*100) W Tolerance value = 3 (*100) W Optimal real power = 71 (*100)W List of detected appliances' states: app 1 (Toast Oven) state 0 (14) app 0 (Dryer) state 0 (57) Dryer +Toast Oven Benefit Table 22

State Table Error Detection • Motivation: State table changes frequently • New appliance • Existing appliance turned off at learning phase • State Table Error Detection in Meter • Initiate Reactive relearning from meter • Three types of error • |Observed Load – Detected Load| > a threshold • An appliance changes state too often (appliance dependent) parameters: monitoring period, acceptable change rate • #appliance changing state in one edge event > a threshold 23

Learning Phase at Head Ends ref: M. Baranski and V. Jurgen (2004) Implemented in Java with Java Genetic Algorithm Package (JGAP) Input Output Edge Events Appliance Table 25

Clustering Algorithm time time time time • Procedures • Retrieve first event and search the rest for matching events by assigning the first event to a new cluster • Difference of power should be below threshold • Every time it finds a new matching event, update the power value of current cluster by averaging all values in the cluster • Assign on/off events with the same absolute power values to the same cluster • Calculate the mean and standard deviation of the cluster • Repeat the above procedures for the events that have not been assigned to any clusters yet • Input • Edge events • Output • Clusters of on/off events 26

Appliance Table Building Algorithm GA DP • Input • Edge detection result • Clustering result • Output • Appliance state table • Steps • Selection of promising combinations of clusters • Initialization of FSM • Optimization of FSM 27

Appliance Table Building AlgorithmStep1: Selection of promising combinations of clusters eg) 1 1 1 0 0 +100W, +50W, -150W 0 0 0 1 1 X = ( ) +1500W, -1500W 1 1 1 1 1 +100W, +50W, -150W, +1500W, -1500W • Make combinations of clusters that compose state transitions • There are 2Nc combinations (Nc: # of clusters) • Impossible to examine all combinations when Nc is large • Select promising combinations by Genetic Algorithm • Sum of power values should be close to 0W +100W, +50W, -150W +100W, -1500W • Inputs • Edge events • Clusters eg) +100W, +50W, -150W, +1500W, -1500W • Intermediate Output: Matrix X (binary) • Column: each cluster • Row: promising combination of clusters 28

Appliance Table Building AlgorithmStep2: Initialization of FSM Valid Invalid +100W +50W -150W +100W -150W +50W +100W +100W 0W 100W 0W 100W 1 1 1 0 0 +100W, +50W, -150W 0 0 0 1 1 X = ( ) +1500W, -1500W 1 1 1 1 1 -150W +50W +50W -150W +100W, +50W, -150W, +1500W, -1500W 150W -50W • Select the best sequence pattern of clusters (Finite State Machines) • Assumption: each cluster (state transition) should appear exactly once • There are N1! permutations (N1: # of 1s in a row of X) • Impossible to examine all permutations when N1 is large • Put an upper limit on N1 in Step1 • Examine validity of each permutation • Powers should not be less than 0W in the middle of state transitions • Powers should not be 0W (off state) in the middle of state transitions • Powers should be 0W (off state) in the last state transitions 29

Appliance Table Building AlgorithmStep2: Initialization of FSM (cont’d) Combination: +100W, +50W, -150W Valid sequences: +100W +50W -150W +50W +100W -150W • Select the best sequence pattern of clusters (Finite State Machines) • Make the best path by Dynamic Programming for each pattern • Properties used as the quality of each sequence • Time duration between state changes in a sequence • Deviation between the observed power value and the corresponding value of the cluster • Target value of each property is first set to the median of the all corresponding events • The closer to the target value, the better • Once the best path is created, update each target value with the median of the best path, and repeat the process until it fails to achieve better quality • Select the best sequence pattern • Frequent pattern is better • If the frequencies are the same, then select the pattern whose quality is the best 30

Appliance Table Building AlgorithmStep3: Optimization of FSM 1 1 1 0 0 +100W +50W -150W 0 0 0 1 1 X = ( ) +1500W -1500W 1 1 1 1 1 +1500W +100W -1500W +50W -150W Solve overlaps 1 1 1 0 0 +100W +50W -150W X = ( ) 0 0 0 1 1 +1500W -1500W • Solve the overlaps of clusters • Assumption: each cluster (state transition) should appear for exactly one appliance • Select the best appliance based on the quality value among the appliances that share the same clusters (state transitions) • Recreate the finite state machines for non-best appliances without the overlapped clusters • If there are no valid sequences, then exclude the appliances 31

Appliance Table Building AlgorithmTest Result 1 • Tested the algorithm using the example data • Edge events and corresponding clusters were generated as an ideal representation of the example data • Was able to build a correct appliance table • Confirmed that it can create a multiple state FSM

Appliance Table Building AlgorithmTest Result 2 • Tested the algorithm using data from a controlled test • Edge events and corresponding clusters were generated as an ideal representation of the collected data • Was able to correctly detect five different appliances used in the controlled test

Relearning Phase at Head Ends Day 1 Day 2 Day 3 Day 4 • Head end starts to build appliance tables • Upon requests from the meter (reactive) • Periodically (proactive) • Assumption: Similar appliance profiles should be observed over multiple days • Residents use the same appliances every day • Procedures • Examines the appliance tables created from multiple sets of data • If it finds an appliance whose state transition profile is different from that of the previously detected appliances, then it judges that a new appliance has been added • Ends the learning period when it does not find new appliances for a set period of time Power Power Power Power State # State # State # State # new appliance has been added 34

Background • Overview • On-board Algorithms • Back-end Algorithms • Results and Conclusions

Test Home #1: Controlled Test 61 Events Total Toaster Garage Dryer Oven 2 Oven 1

Appliance 1 = Oven 1 or Dryer Power difference only 10 Watts Appliance 2 = Second Oven Appliance 3 = garage door opener Appliance 4 = state for noisy lights Missing toaster oven! Why? Appliance Table Generation 4, 0, 0, 5615, 122 4, 1, 0, 2311, 136 4, 2, 0, 393, 85 4, 3, 0, 872, 142

Results in Test Home Real Power Load Data in Test Home’s Kitchen (Dec 2nd) Incorrect:Dryer + 2nd Oven Correct:Dryer +Toast Oven Correct:Dryer Correct:Dryer Incorrect:Dryer Correct:Toast Oven Correct:Toast Oven Incorrect:Garage Door Opener Correct:Garage Door Opener 38

Ran with previously defined state table on 3 days of data Looking for the oven signature Found on 12-12-09 Not found on 12-10-09 or 12-11-09 Sample output: 12/11/2009 7:39:30 1st_Oven On 12/11/2009 7:39:51 1st_Oven Off Real Testing Real Power (W) Time (s)

Test House #2 from 11-3-09 Compressor AC #1 AC #1 AC #2 AC #2 Compressor Air Handler Air Handler Time • Test house #2 had two main AC units • Goal: Find these units

Clustering from 11-3-09 AC #1 On AC #2 On AC #2 Off Reactive Power(VAr) AC #1 Off

State generating algorithm correctly identified both AC units Impressive since it only takes real power into account Also realized that the first air conditioner was a two state appliance Missed the second state on AC #2 Generated State Table (Other Results Omitted) 7, 4, 0, 2400, 50 7, 5, 0, 3650, 150 7, 5, 1, 851, 104 Generate State Tables

Meter Monitoring • We surmise that one day of learning is not sufficient • Based on Data we would with assume the AC ran on 11/7/2009 and 11/26/2009

Bandwidth for Test House #1 • With Above Threshold had less than 1000 events per day • That is less than 1% of original data • Or assuming 24B per reading under 15 kB per day

Bandwidth for Test House #2 • With Above Threshold had less than 2000 events per day • That is less than 2.5% of the original data • Or assuming 28B per reading under 60 kB per day

Appliance Tables • Generated Appliance Tables for three days from November and December • Same appliances were identified over the three days • Appliance tables are unique

Conclusions • The Event Detection Algorithm cut down the data to under 2% in our testing • This should easily be transmittable to the head end for processing • The learning phase produced distinguishably different state tables in different environments furthermore, similar appliances were found over separate learning periods in the same environment • The meter monitoring algorithm worked well if: • It had a completely accurate state table • All appliances had distinguishably different loads

Further Research • Are there more ways to classify appliances other than through real/reactive power? • Maybe use the frequency of the event • Maybe use the time of day • What improvements can be made to NILM without access to anything other than real power? • Must be improved for use. • How long does the meter need to be in learning mode to pick up all appliances? • We suspect this is dependant on the habits of the residents.

Questions • Feel free to ask away….. Thank you Carl, Andrew, and Michael!

Non-Intrusive Demand Response Verification