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

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

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

4. 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

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

6. 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

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

8. Monitoring Phase 8

9. 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

10. Learning Control Scheme10

11. Learning Phase 11

12. 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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

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

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

22. 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

23. 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

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

25. 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

26. 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

27. 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

28. 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)
+100W, +50W, -150W
X = ( )
+1500W, -1500W
+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

29. Appliance Table Building Algorithm Step2: Initialization of FSM
Valid
Invalid
+100W W W
+100W W W
+100W
+100W 0W
100W 0W
100W
+100W, +50W, -150W
X = ( )
+1500W, -1500W
-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

30. Appliance Table Building Algorithm Step2: Initialization of FSM (cont’d)
Combination:
+100W, +50W, -150W
Valid sequences:
+100W W W
+50W W W
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

31. Appliance Table Building Algorithm Step3: Optimization of FSM
+100W W W
X = ( )
+1500W W
+1500W W W
+50W W
Solve overlaps
+100W W W
X = ( )
+1500W W
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

32. 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

33. 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

34. 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

35. Background
Overview
On-board Algorithms
Back-end Algorithms
Results and Conclusions

36. 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

37. 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

38. 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

39. Real Testing Ran with previously defined state table on 3 days of data
Looking for the oven signature
Found on
Not found on or
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)

40. 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

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

42. 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

43. 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

44. 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

45. 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

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

47. 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

48. 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.

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