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