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

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

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

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

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

Proposed Monitoring Scheme AMI headend billing system utility web portal customer web portal Internet load shed request verification customer network pricing display smartphone smart meter DR gateway PC HVAC fridge plugin hybrid pool pump solar panels 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

Problems Our Scheme Addresses 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 12

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

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 Algorithm 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 Above Threshold 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 Benefit Table 22 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 App \ Load (100W) 1 … 70 71 72 73 74 75 76 1 (Dryer) 57 2 (Toast Oven) 3 (Garage) 66 4 (First Oven) 5 (Second Oven) 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

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

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 Procedures Input Output time time time time 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 Input Edge detection result Clustering result Output Appliance state table Steps Selection of promising combinations of clusters Initialization of FSM Optimization of FSM DP 27

Appliance Table Building Algorithm Step1: Selection of promising combinations of clusters Inputs Edge events Clusters eg) +100W, +50W, -150W, +1500W, -1500W Intermediate Output: Matrix X (binary) Column: each cluster Row: promising combination of clusters eg) 1 1 1 0 0 +100W, +50W, -150W X = ( ) 0 0 0 1 1 +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 28

Appliance Table Building Algorithm Step2: 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 X = ( ) 0 0 0 1 1 +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 Algorithm Step2: 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 Algorithm Step3: Optimization of FSM 1 1 1 0 0 +100W +50W -150W X = ( ) 0 0 0 1 1 +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 Algorithm Test 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 Algorithm Test 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 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 State # Day 1 Power State # Day 2 Power State # Day 3 Power State # Day 4 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 5, 0, 1, 5745, 200 : dryer 5, 1, 1, 1475, 45: toaster oven 5, 2, 1, 905, 85: garage 5, 3, 1, 5735, 55: first oven 5, 4, 1, 2205, 55: second oven Garage Dryer Oven 2 Oven 1

Appliance Table Generation 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? 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

Real Testing 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 Power (W) Time (s)

Test House #2 from 11-3-09 Test house #2 had two main AC units Compressor AC #1 AC #1 AC #2 AC #2 Compressor Air Handler Air Handler Tall peek is the compressor Smaller peak is the 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 AC #1 Off Reactive Power (VAr) AC #1 Off

Generate State Tables 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

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 Thank you Carl, Andrew, and Michael! Feel free to ask away….. Thank you Carl, Andrew, and Michael!