non-intrusive demand response verification david bergman, kevin jin, joshua juen, naoki tanaka cs563...
TRANSCRIPT
Non-Intrusive Demand Response Verification
David Bergman, Kevin Jin, Joshua Juen, Naoki Tanaka
CS563 – Fall 2009
• Background• Overview• On-board Algorithms• Back-end Algorithms• Results and Conclusions
2
Consumer Smart Grid Architecture
billingsystem
AMIheadend
smartmeter
pricing display
HVAC poolpump
customerweb portal
smartphone
DR gateway
pluginhybrid
utilityweb portal
fridge solarpanels
Internet
PC
customernetwork
From Andrew Wright’s Smart Grid Neutrality Presentation 3
Non-Intrusive Load Monitoring (NILM)
Heater
Dishwasher Oven
Heater
4
• Background• Overview• On-board Algorithms• Back-end Algorithms• Results and Conclusions
5
Proposed Monitoring Scheme
billingsystem
AMIheadend
smartmeter
pricing display
HVAC poolpump
customerweb portal
smartphone
DR gateway
pluginhybrid
utilityweb portal
fridge solarpanels
load shed requestload shed request Internet
PC
customernetwork
verificationverification
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
• Background• Overview• On-board Algorithms• Back-end Algorithms• Results and Conclusions
13
Meter Architecture Design
14
• Learning PhaseReal-Time Load Data → Edge Detection (Edge Events)→ Headend (state table) →Meter
• Monitoring PhaseReal-Time Load Data → Edge Detection (Edge Events)→ Appliance Detection
(updated states) → State Table(error states) → Relearning Phase
Edge Detection Algorithm
Source
Edge Detection Module
15
Goal: Detect abrupt changes in powers reading and output “edge events”
SEL734
TED1000
TED5000
Above Threshold
Step Average
Edge Events
Edge Detection Module
16
Above Threshold– Less state, fast– Capture spikes
Step Average– Better compression– Not sensitive to transient
events
Pow
er (
W)
Time (s)
• 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
Appliance Detection Module
17
Appliance Detection Module
18
Edge Detection
State Table
Appliance DetectionEdge Events
Update
AMI Head End
Appliance Profiles
Load Shedding Request
Load Shedding Response
Relearning Request
Appliance Detection Algorithm
19
• 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.
Appliance Detection Algorithm
20
• Knapsack algorithm on Edge Events• Problem formularization as 0-1 knapsack problem
Appliance Detection Pseudo Code and Complexity Analysis
21
Reference: Dr. Steve Goddard, Dynamic programming, Knapsack problem http://www.cse.unl.edu/~goddard/Courses/CSCE310J
For total n states:• A brute force approach: O(2n)• Our approach: O(n(W+T)/M)
W+T: total weightM: minimum detection power unit
E.g. 10 appliances with 2 states eachn = 20, W = 5000W, T = 500W, M=100W
O(220) vs O(20*55)
Example
22
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
6: 06: 55
6: 07: 03
6: 07: 12
6: 07: 21
6: 07: 29
6: 07: 38
6: 07: 47
6: 07: 55
6: 08: 04Ti me (s)
Real
Pow
er (
W)
rawEdge Events
Dryer +Toast Oven
App \ Load(100W) 0 1 … 70 71 72 73 74 75 76
0 0 0 … 0 0 0 0 0 0 0
1 (Dryer) 0 0 … 57 57 57 57 57 57 57
2 (Toast Oven) 0 0 … 57 71 71 71 71 71 71
3 (Garage) 0 0 … 66 71 71 71 71 71 71
4 (First Oven) 0 0 … 66 71 71 71 71 71 71
5 (Second Oven) 0 0 … 66 71 71 71 71 71 71
Benefit Table
Edge detected: 12/2/2009 6:07:18
Observed Real Power = 73 (*100) WTolerance 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)
State Table Error Detection
23
• 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
• Background• Overview• On-board Algorithms• Back-end Algorithms• Results and Conclusions
24
Learning Phase at Head Ends
25
Edge EventsEdge Events Appliance Table
Appliance Table
Input Output
ref: M. Baranski and V. Jurgen (2004)
Implemented in Java with Java Genetic Algorithm Package (JGAP)
• Input– Edge events
• Output– Clusters of
on/off events
Clustering Algorithm
26
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 detection result– Clustering result
• Output– Appliance state table
• Steps– Selection of promising
combinations of clusters
– Initialization of FSM– Optimization of FSM
Appliance Table Building Algorithm
27
GAGA
DPDP
• Inputs– Edge events– Clusters
eg) +100W, +50W, -150W, +1500W, -1500W
• Intermediate Output: Matrix X (binary)– Column: each cluster– Row: promising combination of clusters
Appliance Table Building AlgorithmStep1: Selection of promising combinations of clusters
28
– 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
X = ( )1 1 1 0 0
0 0 0 1 1 +100W, +50W, -150W
+1500W, -1500W
+100W, -1500W
1 1 1 1 1 +100W, +50W, -150W, +1500W, -1500W
eg)
Appliance Table Building AlgorithmStep2: Initialization of FSM
29
– 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
0W0W 100W100W
150W150W
+100W
+50W-150W
0W0W 100W100W
-50W-50W
+100W
-150W+50W
Valid Invalid
X = ( )1 1 1 0 0
0 0 0 1 1 +100W, +50W, -150W
+1500W, -1500W
1 1 1 1 1 +100W, +50W, -150W, +1500W, -1500W
+100W +50W -150W +100W -150W +50W
Appliance Table Building AlgorithmStep2: Initialization of FSM (cont’d)
30
+100W, +50W, -150W
+100W +50W -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
+50W +100W -150W
Combination:
Valid sequences:
Appliance Table Building AlgorithmStep3: Optimization of FSM
31
– 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
X = ( )1 1 1 0 0
0 0 0 1 1 1 1 1 1 1
+100W +50W -150W
+1500W -1500W
+1500W +100W -1500W +50W -150W
Solve overlaps
X = ( )1 1 1 0 0
0 0 0 1 1 +100W +50W -150W
+1500W -1500W
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
32
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
33
Relearning Phase at Head Ends
34
– 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
Pow
er
State #
Day 1
Pow
er
State #
Day 2
Pow
er
State #
Day 3
Pow
er
State #
Day 4
new appliance has been added
34
• Background• Overview• On-board Algorithms• Back-end Algorithms• Results and Conclusions
35
0
1
2
3
4
5
6
7
8
9
10
5
:55
:00
5
:55
:46
5
:56
:32
5
:57
:21
5
:58
:07
5
:58
:53
5
:59
:39
6
:00
:25
6
:01
:13
6
:01
:59
6
:02
:45
6
:03
:31
6
:04
:17
6
:05
:03
6
:05
:49
6
:06
:35
6
:07
:21
6
:08
:07
6
:08
:53
6
:09
:39
6
:10
:25
6
:11
:11
6
:12
:00
6
:12
:46
6
:13
:32
6
:14
:18
Time
Po
wer
(kW
)
61 Events Total
Test Home #1: Controlled Test
DryerGarageToaster
Oven 1Oven 2
36
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, 1224, 1, 0, 2311, 1364, 2, 0, 393, 854, 3, 0, 872, 142
37
Results in Test Home
38
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
5:54:14 5:57:07 6:00:00 6:02:53 6:05:46 6:08:38 6:11:31 6:14:24 6:17:17
Time (s)
Real P
ow
er (W
)
Meter Reading
Step Average
Real Power Load Data in Test Home’s Kitchen (Dec 2nd)
Correct:Dryer
Correct:Toast Oven
Incorrect:
Dryer
Correct:Garage Door
Opener
Incorrect:Dryer + 2nd Oven Correct:
Dryer +Toast OvenCorrect:
Dryer
Correct:Toast Oven
Incorrect:Garage Door
Opener
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
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
7:37
:47
7:38
:15
7:38
:43
7:39
:11
7:39
:39
7:40
:07
7:40
:35
7:41
:03
7:41
:31
7:41
:59
7:42
:27
7:42
:55
7:43
:23
7:43
:51
7:44
:19
7:44
:47
7:45
:15
7:45
:43
7:46
:11
7:46
:39
Time (s)
Rea
l Pow
er (W
)
Time (s)
Rea
l P
ow
er (
W)
39
Test House #2 from 11-3-09
• Test house #2 had two main AC units
• Goal: Find these units
AC #1
AC #2
Time
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
11:0
8:26
11
:08:
55
11
:09:
24
11
:09:
53
11
:10:
22
11
:10:
51
11
:11:
20
11
:11:
49
11
:12:
18
11
:12:
47
11
:13:
16
11
:13:
45
11
:14:
14
11
:14:
43
11
:15:
12
11
:15:
41
11
:16:
10
11
:16:
39
11
:17:
08
11
:17:
37
11
:18:
06
11
:18:
35
11
:19:
04
11
:19:
33
11
:20:
02
Time
Po
wer
(W
or
VA
)
Real Power
Reactive PowerAC #1 AC #2Compressor
Air Handler
Compressor
Air Handler
40
Clustering from 11-3-09R
eact
ive
Po
wer
(VA
r)
AC #1 Off
AC #2 Off
AC #1 On
AC #2 On
41
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, 507, 5, 0, 3650, 1507, 5, 1, 851, 104
42
Meter Monitoring
0
5
10
15
20
25
30
35
11/3
/200
9
11/5
/200
9
11/7
/200
9
11/9
/200
9
11/1
1/20
09
11/1
3/20
09
11/1
5/20
09
11/1
7/20
09
11/1
9/20
09
11/2
1/20
09
11/2
3/20
09
11/2
5/20
09
11/2
7/20
09
11/2
9/20
09
Date
# T
imes
Fo
un
d
AC #1
AC #2
• 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
43
# Events Per Day
0
200
400
600
800
1000
11/1
3/200
9
11/1
5/200
9
11/1
7/200
9
11/1
9/200
9
11/2
1/200
9
11/2
3/200
9
11/2
5/200
9
11/2
7/200
9
12/9
/200
9
12/1
1/200
9
Days
# E
ven
ts
Step Average
Above Threshold
Compression Per Day
0.0%
0.2%
0.4%
0.6%
0.8%
1.0%
1.2%
11/1
3/200
9
11/1
5/200
9
11/1
7/200
9
11/1
9/200
9
11/2
1/200
9
11/2
3/200
9
11/2
5/200
9
11/2
7/200
9
12/9
/200
9
12/1
1/200
9
Days
Co
mp
ress
ion
%
kB Per Day House #1
0
5
10
15
20
25
Days
KB
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
44
Bandwidth for Test House #2# Events Per Day
0500
10001500200025003000350040004500
11/3
/200
9
11/5
/200
9
11/7
/200
9
11/9
/200
9
11/1
1/20
09
11/1
3/20
09
11/1
5/20
09
11/1
7/20
09
11/1
9/20
09
11/2
1/20
09
11/2
3/20
09
11/2
5/20
09
11/2
7/20
09
11/2
9/20
09
Days
# E
ven
ts
Step Average
Above Threshold
Compression Rates Per Day
0.0%
1.0%
2.0%
3.0%
4.0%
5.0%
11/3
/200
9
11/5
/200
9
11/7
/200
9
11/9
/200
9
11/1
1/20
09
11/1
3/20
09
11/1
5/20
09
11/1
7/20
09
11/1
9/20
09
11/2
1/20
09
11/2
3/20
09
11/2
5/20
09
11/2
7/20
09
11/2
9/20
09
Days
Co
mp
ress
ion
%
kB Per Day Learning
0
20
40
60
80
100
120
11/3
/200
9
11/5
/200
9
11/7
/200
9
11/9
/200
9
11/1
1/20
09
11/1
3/20
09
11/1
5/20
09
11/1
7/20
09
11/1
9/20
09
11/2
1/20
09
11/2
3/20
09
11/2
5/20
09
11/2
7/20
09
11/2
9/20
09
Days
KB
• 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
45
Appliance Tables
• Generated Appliance Tables for three days from November and December
• Same appliances were identified over the three days
• Appliance tables are unique
46
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
47
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.
48
Questions
• Feel free to ask away…..
Thank you Carl, Andrew, and Michael!
49