Non-Intrusive Demand Response Verification

mundanemushroomsElectronics - Devices

Nov 21, 2013 (3 years and 11 months ago)

75 views


1



Abstract


This paper seeks to design and implement a demand
response verification system based off of a non
-
intrusive
load monitoring scheme in order to

verify load reduction
in

a

consumer’s home without the need for appliance
level communication
A

new method of
demand response
verification is presented which is

designed to run on low
power hardware in a limited communication
environment. . In order to mi
nimize the impact on the
home consumer, the system is self
-
learning and requires
no special setup or pre
-
existing knowledge of the
environment. In order to satisfy the low bandwidth and
low power consumption requirements, the calculation
intensive non
-
intr
usive load monitoring is conducted on
the head end for a limited learning phase until the
environment is known. A less computationally intensive
method is used on the smart meter to monitor the actual
state of the appliances in real time. A prototype was
designed and tested using numerous lab experiments and
real data collected from two homes over the course of the
month of November. The tests reveal that the prototype
can be used to determine if large appliances are
currently on in a home solely based off

of the aggregate
power data if the appliance table is known. By using a
limited learning phase, it is possible to get this
application table even in a resource constricted
environment.
This new method of demand response
verification shows great promise in

simplifying the
deployment of the new smart grid


1
.

Introduction


In
the newly proposed smart grid, residential
consumers are going to be encouraged to participate in
demand response programs. These programs will
be
implemented

for load reduction during
periods of
strenuous energy use in order to keep
power
demand
under control.
When designing energy programs for
residential use, the goals are to keep the policies as simple
as possible. While it is acceptable in commercial
scenarios for the policy to dict
ate the amount of energy to


shed in actual kilowatt hours, the average consumer’s
lack of experience with electricity requires a simpler
approach to be taken. Thus, instead of telling consumers
to simply cut down their energy use, it has instead been
sugge
sted to tell consumers what specific appliances they
should turn off. One way this could be implemented
would be by suggesting that consumers turn off specific
appliances at specific times in order to save money on
their electricity bill. Another idea woul
d be to offer a
discount rate on electricity to run high power devices
during lower demand times. For example, if the customer
owned a hybrid electric vehicle, a discount could be
offered to consumers who elected to charge their vehicle
between the hours o
f midnight and six in the morning, a
traditionally low power use period of the day. By
encouraging the use of electricity during off peak times,
the stress on the power grid will be reduced and power
production efficiency will be increased.

According to cu
rrent proposals, load reduction will be
confirmed using communication between the smart
meters in the home and the individual appliances. This
scheme has a number of apparent security problems

as
outlined in the NISTIR security report [1]
. First, each
appl
iance must be trusted to report the correct usage in an
un
-
trusted environment. This has lead to numerous
proposals involving remote attestation in order to confirm
the correct operation of each appliance’s reporting and to
deter the tampering of the actua
l appliance’s reporting
system. Furthermore, the communication to the meter
needs to be both reliable and secure from communication
tampering in order to
prevent malicious users from
hack
ing

the results
in order
to
manipulate the appliance’s
reporting. Sin
ce the primary purpose of the meter is to
report power use for billing information, the threat level
and possibility of malicious users is present, and the
power company has a high priority to keep the data
integrity correct. In addition to

integrity
probl
ems,

the
transmission of data also introduces numerous privacy
and confidentiality issues. Specifically, the wireless
communication proposed between the appliances and the
meter could give away information regarding the types of
appliances in the home

to a

remote attacker
. This has lead
to the proposal of intricate schemes of asynchronous
private keying in order to secure the wireless
communication

channel
. Unfortunately, the size and
Non
-
Intrusive Demand Response Verification

David Bergman, Joshua P. Juen, Kevin Jin, and Naoki Tanaka


2

scale of the deployment of the keying

infrastructure

introduces numerous
problems in order to establish the
initial keys in a way which is transparent to the common
home owner.
This is an important difficulty to overcome
since the transparency to the residential user is critical in
a viable implementation.
Finally, it has been
demonstrated that simply observing the wireless
communication itself could lead to security leaks about
when the occupants are home and what kind of
daily
activity patterns they follow[2].

In this paper, we will investigate the possibility of
circumventing

these problems by attempting to confirm
the reduction in load by only looking at the aggregate
power consumption at the meter itself. The idea of
determining individual loads from aggregate
data
is well
researched through various non
-
intrusive load monito
ring
(NILM) techniques. These techniques use various data
including real power, reactive power, and current. More
sophisticated methods make use of frequency analysis
techniques in order to analyze aggregate loads. This
paper will investigate the use of si
mpler NILM
algorithms in order to determine the state of different
appliances. The goal will be to implement a system that
can accurately identify the on or off state of significant
household loads. The design of the system will be
optimized to run on limi
ted meter hardware and maintain
communication with the head
-
end through a low
bandwidth channel. Furthermore, the system will be
designed to automatically learn about appliances in the
consumer’s home without any prior knowledge or special
programming phas
e.
Thus, the system will require no
special effort or knowledge and will be completely
transparent to the average home consumer.
The rest of the
paper is organized as follows. Part two will outline
related work used as a foundation for the non
-
intrusive
lo
ad monitoring techniques employed in the prototype.
Part three will present a new demand response and
verification system designed to run on limited hardware.
Part four will present a step by step analysis of a test run
through the system. Part five will p
resent testing data to
analyze key components of the system. Finally, part six
will present the conclusions and results in addition to the
future work planned.












2.

Background and Related Work



Figure
1

Typical Real Powe
r Graph



In order to eliminate the need for communication with
individual appliances, the meter must be able to ascertain
the individual appliance state based solely on the
aggregate power data. As seen in figure #1, the detection
of individual appliance
use is possible due to the nature of
power loads [8]. The key observation is that most large
appliances consistently use the same power as they turn
on and off [4]. This makes it possible to look at the
overall graph of power use and identify the step chan
ges
as distinct appliance on and off events.

These
observations led to the conception of non
-
intrusive load
monitoring. Originally conceived by George Hart [3], the
first NILM analyzed a power graph in order to determine
the on or off state of key applianc
es. The method first
parsed the power use to find the step transitions and
compiled them into a list. It then parsed the list and
grouped the appliances by similar power use and matched
similar on power steps to off power steps. This process of
matching ev
ents is known as clustering. Once clustered,
the algorithm would look at events which lacked matches
and search for multiple simpler events which could
explain the anomalies. The purpose of this process is to
reduce error caused by the step changes caused
by two or
more appliances changing at the same time. While the
process was successful, the accuracy of the algorithm was
limited due to a lack of granularity with the power
measurements due to similar power requirements across
multiple loads. The algorithm

also had difficulties
detecting loads which have multiple states. Finally, the
method assumed previous knowledge of the appliances
which were being monitored. This required some form of
training phase.


3


Research into non
-
intrusive load monitoring has
foc
used on allowing the methods to detect smaller
signatures and to distinguish between signatures even if
the differ by as little as ten watts [6]. The first method to
increasing the granularity of NILM methods was to
introduce reactive power into the detect
ion. This allowed
the original NILM method to identify similar real power
loads based on the reactive signature thus giving a two
dimensional space in which to classify the clusters of
appliances [3]. While this helped the granularity,
multi
-
state applianc
es were still problematic. The next
stage of development was to introduce state machines
into the algorithm which would represent the different
states that a complex load would traverse throughout its
operating cycle. This allowed the NILM to accurately
fi
nd appliances such as washing machine or other
complex loads. More recently, signal processing
techniques have been introduced to analyze loads for the
frequency signatures of loads. The final problem to be
handled by current methods is the elimination of
pre
-
determined knowledge of the operating environment.
The initial method to eliminate training was to simply
include a vast database of load profiles for the monitoring
to match. This was problematic due to the variation of
real load values among applianc
es. More sophisticated
research has used genetic algorithms and neural nets to
introduce an adaptive learning algorithm to determine the
correct appliances automatically [4][5][7]. Using these
techniques has allowed commercial NILM to accurately
represent
small loads with high accuracy without any
prior training or knowledge of the operating environment.


While accurate, current NILM techniques are ill suited
for use in demand response verification due to the high
computational requirements and advanced me
tering
required to take the data. For example, the genetic
algorithms to eliminate the intrusive training phase takes
ten minutes to run on a Pentium four three gigahertz
machine while the typical smart meter is running at below
a hundred megahertz. Furthe
rmore, advanced techniques
such as the frequency analysis require meter readings at
the millisecond scale while the meter can take a
maximum of one reading per second [6]. Thus, the low
processing power on the meter prohibits the use of
advanced NILM techn
iques. Computational constraints
could be overcome by having the meter transmit all
readings back to the head end for processing.
Unfortunately, this is unrealistic due to the bandwidth
constrains on the communication between meter and head
end. If the met
er takes one reading per second which
contains a data, a real power reading, and a reactive
power reading, this would require more bandwidth than is
available to each individual meter on the network. Thus, a
method for NILM must be developed in order to
ov
ercome the computational expense of the NILM and
bandwidth constraints of the channel while still allowing
the meter to accurately detect appliances and learn about
the environment without initial setup.





3.

Non
-
Intrusive Demand Response
Verification


Power Company Headend


Smart Meter
Appliance
Detection
State Table
Edge
Dectection
Real
-
Time
Load Data
Compression
Module
ZigBee
Communication Interface
Clustering Events
Creating FSM
(
Generic Algorithm
)
Optimizing FSM
(
Dynamic Programming
)
Communication Interface
Headend Controller
Real
-
Time Monitoring Data Flow
(
Re
)
LearningPhase Data Flow
(
Re
)
Learning Phase Control Flow
Load Shedding Control Flow

Figure
2

Prototype Overview


Overview:


In order to overcome the limitations on
bandwidth and computing power, the analysis of the
aggregate data will be divided between the meter and the
head end. The

key observation is that the first step in
typical NILM is the scanning for discrete step events, a

4

process which is not computationally expensive. This
allows the meter to cut down the amount of data by close
to ninety
-
nine percent. Furthermore, it is sur
mised that
with an accurate table of application’s step power
changes, a simple matching algorithm could be employed
to identify large appliance loads even in noisy data. These
observations led to the following scheme composed of
two phases. In the normal
operating phase, the meter will
take readings and conduct real time edge detection. Upon
encountering an edge, it will look at a table of appliances
and load signatures and use a simple matching algorithm
in an attempt to detect what appliances are current
ly on
and off in the house. It will then update the table in order
to reflect what appliances are currently running. By
keeping this table up to date, the meter will always be
prepared to respond to verification requests from the head
end. The second phase

is designed to identify what
appliances are currently active in the meter’s
environment. During this phase, the meter will collect
data and parse edge events, but will then transmit them
back to the head end. The head end will then collect data
over a per
iod of time and conduct more advanced
computationally intensive non
-
intrusive load monitoring
techniques in order to ascertain the appliances which are
running in the home. Thus, more advanced techniques
will be leveraged in ways which overcome hardware
li
mitations. Our prototype implements a simple clustering
analysis of the events and then develops a state table
using a genetic algorithm to optimize a set of possible
finite state machines. In order for this scheme to be
viable, it is necessary to confirm
that the metering data
can be compressed reasonably enough to send, that the
meter can find appliances based off of an accurate state
table, and that a reasonable learning phase will allow the
head end to identify such appliances. Furthermore, it
would be
nice if the scheme did not require reactive
power.



Edge Detection

As a part of both the learning phase and the monitoring
phase, the first
goal of the meter is to detect abrupt
changes in the power readings.

T
hese
major
changes
correspond to applianc
es in the household changing state
.
Thus, the motivation for our event detector is to simply
produce an output whenever there is sufficient change

from the current power value to signify a large appliance
either turning on or off. The algorithm will thus i
gnore
minor changes thus allowing the meter readings
happening every second to be represented in a
compressed form.


The input for this algorithm is a series of power data
tuples. Depending on the source, this tuple typically
includes the following: {ti
me stamp, real power value,
apparent power value, reactive power value}.
For
robustness, the algorithms are also written to handle
sources that do not measure reactive power.

Hence,
sometimes our tuple is represented as {time stamp, real
power value}. I
n either case, we use a series of tuples as
our input and create a series of tuple
s

with the same
format as our output. These output tuples repre
sent
sudden changes in power, produced when an appliance
changes state.

The manner in which we generate these
output tuples
depends on a few parameters. The most important
parameter that we have is which algorithm to use.
Currently, we have two such algorithms implemented,
though we are investigating others that may produce
better results (as measured
by

speed,
memory
consumption, accuracy, and compression
characteristics).


The general flow of this module is as follows:

getNextData
: This can be done in a number of ways,
through hard
-
coded data, text files, or from a live meter.
It reads in a single tuple and
passes it to averageData.


averageData
: This phase averages a number of data
points (set at compile time) and creates a new data stream
of data. This helps to smooth spikes that can occur when
the system is not in steady state.


detectEvent
: This
examines

the

data stream and look
s

for
points in time

where there are sudden changes in
readings. We have a few different algorithms
implemented and will discuss them below.


outputEvent
: Whenever an event is detected, we must
decide what to do with it. We can e
ither print it to a log
file for future batch compression, we can send it directly
to the head

end, or we can send it

to

another module on
board that handles the state table.


compressEvents
: Currently, we do not have any
compression enabled. However, the
re is a stub here for
compressing the log file before it gets sent to the head

end.


sendEventLog
: Currently, we do not have the capability
to send the event log anywhere. However, there is a stub
here for when we get that communication path working
corre
ctly.


The most interesting work here h
as been on
determining when an event occurs. The first such
detection algorithm we have implemented is the
above
threshold

algorithm.


5

The a
bove

t
hreshold

algorithm is simple in that it
carries very little state. I
t starts with
one latched tuple
(starts with

null time stamp and power values). As a new
power reading appears, the new power value is compared
to the latched power value. If this difference is larger
than some threshold, the algorithm presents this stat
e as
new output. It then latches this tuple for comparison
against future values.

The second algorithm developed was called the step
average

algorithm
. Compared to the above threshold
algorithm, the step threshold

is more complicated

but
produces a bett
er compression of events
.
The algorithm
keep
s

a running average of power values for a window of
data. Every time a new is detected
, represented by a
change above a predefined threshold
, the current running
average is output as an event corresponding to t
h
e time
from the beginning of that

period. Next, the running

average gets reset and the algorithm mov
es on to the
next period
. We have also included the notion here of
stability that is
impossible to implement in the
previously
mentioned

a
bove

t
hreshold algorithm

without more state

being added
. A value has to be constant for a short period
of time before we determine that an event has occur
r
ed.
In this manner, we avoid transient states.


All of these comparisons (for both algorithms) can be
done with either real power or reactive power. However,
we have noticed that when events occur, both real and
reactive power change at the same time. Thus, we are
only concerned with comparing
chan
ges in real power
and then also recording the corresponding changes in
reactive power
. However,
since
some commercial meters
do not produce reactive power readings
, both algorithms
were written to also process data with real power readings
only.


Monitorin
g Phase

The appliance detection module provides two major
functionalities in
the
real
-
time monitoring phase:


(1) With the help of a pre
-
calculated appliance state table,
it identifies the current states of appliances

by updating
the table

upon receivin
g an edge event from the edge
detection module.


(2)
The appliance detection module also d
etects state
table errors, such as some unknown major appliances
being added to the house. This triggers the meter to enter
the relearning phase, and eventually rece
ive an
update
-
to
-
date state table from the AMI head

end.


The design of the detection module takes two inputs:
the current total real power from an edge event and the
known appliances’ profiles stored in the state table,
which is derived from the AMI head

end
during

the
learning phase. The detection module then efficiently
finds the optimal combination with a modified 0
-
1
knapsack algorithm, and updates the states of all
appliances in the state table. This ensures that that the
most recent state informati
on is always
ready to respond
to a
head

end query.

The state table in the meter
is shown in table #1
. Each
record is the profile of one appliance and includes the
number of states as well as the mean and standard
deviation of the real power (W) of each sta
te calculated
by
the
clustering module in

the

head

end. The
per
-
appliance attributes “monitoring period” and
“acceptable change rate” are used in state table error
detection, wh
ich will be discussed in detail below
.

There are two commonly used methods to
detect the
states of the existing appliances: a knapsack algorithm
and incremental analysis [
10
]. The knapsack algorithm
tries to find the combination of states whose sum power is
maximized under the constraint that the total power is
less than current obs
erved power. The incremental
analysis determines which appliances changed their
states based on the total power change observed in each
edge event. Error propagation is one major drawback of
the incremental analysis, while running knapsack
algorithm contin
uously
TODO
(3 times per second in [])

in real
-
time monitoring phase requires large amount of
computation. Therefore, we propose a hybrid scheme,
which is to run a modified knapsack algorithm on each
edge event.

App

Index

#States

State 1 Mean
Power
(W)

State 1

Std Power

(W)

Monitoring period

(s)

Acceptable
Change rate

1

(dryer)

1

5745

200

3600

8

2

(toaster oven)

1

1475

45

3600

8

3

(garage)

1

905

100

21600

20

4

(first oven)

1

5735

55

3600

8

5 (second oven)

1

2205

55

3600

8

Table #1 A Sample State Table for Carl’s Kitchen



6



The above problem can be formularized as a

0
-
1
knapsack problem:


Max
:


p
i
x
i
, where


w
i
x
i

W

T


W
:

real power observed in edge event.

T
:



tolerance value, w
hich is the sum of the standard
deviation of all possible appliance
s

given the
current load. The appliance who
se mean power
consumption is larger than the current load is
automatically eliminated.


x
i

{
0
,
1
}


on/off of a state of an appliance

w
i


weight of appliance i

p
i


value of appliance i.


In this case, both w
i

and p
i

are the real power consumpt
ion
of appliance i.

The

following pseudo code shows how the knapsack
algorithm works in the detection module, where
B[#appliance][W+T] is the benefit table keeping track of
the best subset of appliances that has a total weight w

[0,
W+T]
:


//initialization of Benefit table

for (w = 0 to W+T)

B[0,w] = 0

for (i = 1 to n)

B[i,0] = 0

// recursively finding the optimal value from
a subset of appliances for every weight w

for (i = 1 to n)

for (w = 0 to W)

if (w
i

<= w) // item i can be part
of the solution

if (bi + B[i
-
1,w
-
w
i
] >
B[i
-
1,w])

B[i,w] = bi +
B[i
-
1,w
-

w
i
]

else

B[i,w] = B[i
-
1,w]

else

B[i,w] = B[i
-
1,w]


//finding the list of selected appliances

i=n, k=W

while (i,k > 0)

if (B[i,k] != B[i
-
1,k])

mark the ith item as in the
knapsack

i
= i
-
1, k = k
-
wi

else

i = i
-
1


A brute force algorithm to detect the optimal
combination [
10
] given a total of n states across all
appliances in the state table requires complexity O(2
n
).
By comparison, the algorithm described above has
complexity O(n(W+T
)/M), where W+T is the total
weight, and M is the minimum detection power unit. For
example, if we have 10 appliances with 2 states each (i.e.
n=20, W = 5000W, T = 500W, M = 100W), the brute
force method requires O(2
20
), while our algorithm
requires only
O(20*55), which is much more desirable to
run on low
-
end meters. The detection algorithm was
tested on the data collected using a TED1000 from Prof

Gunter’s kitchen

(Figure X)
. 90% detection accuracy can
be achieved under the conditions (1) that we use an

accurate state table and (2) that all appliances have
discrete finite states.


Error Detection

The detection module also detects possible errors in the
current state table. These errors can exist due to the fact
that appliances in the household may chan
ge frequently
and also due to the learning phase not being to capture all
states of all appliances. Three types of errors can be
detected in the detection module at present:

1.

If the absolute difference between the observed
total load and detected total load

is greater than
some threshold, then it indicates that some
appliances are missing from the current state
table. Currently, the threshold is set at two times
of the sum of the standard deviation of all
possible states of all appliances.


For example, the
point labeled C1 in Figure X is
supposed to be an event for turning on the toaster
oven. If the toaster oven was missing in the state
table, a missing appliance error
would be

generated from the detection module due to
the
perceived
power difference.


2.

If a
n appliance changes states unreasonably
often, it is a strong indication of error in the state
table. The acceptable change rate is
appliance
-
specific. For example, it is reasonable
to observe frequent change in an air
-
conditioner
or a heater, but it is un
reasonable for a car battery
charger.

For example, an alert was generated at the point
labeled C2 in Figure X. It
occurred due to

the
dryer
c
hang
ing

state eight times within 15
minutes, which we purpose
ly made it do

during
the controlled test.


3.

If the numb
er of appliances changing states
within one edge event is greater than a threshold,
say 5, it is another possible indication of error.
Further analysis will be required to verify if such
a combination of appliance changes violates

7

normal human behavior, in

order to avoid false
positive alerts.


If any one of the three behaviors is observed, the
detection module will trigger its alert routine and send a
request to head

end, indicating there is a need for
re
-
learning the state table.


Learning Phase

Before be
ing able to monitor a household to determine
which appliances are on or off,
the monitoring phase

must
first determine which appliances are present in the house.
In order to do that, we have devised a learning method
which takes advantage of the unique ar
chitecture that will
be present in the smart grid. Namely, every household
will have a small but somewhat competent meter, and a
limited bandwidth connection to the head

end. Hence, we
want all aspects of our design to keep this in mind and
exploit the i
ncongruent computational capabilities.




Communications and Bandwidth


Appliance
Detection
State Table
Edge Dectection
Headend
Controller
Power Company
Smart Meter
Re
-
learning Request
Learning Start
Learning End
Learning Start
Learning End
Headend
-
Controlled Hybrid Scheme of Re
-
Learning Phase
{
Learning Period
{
Learning Period
Reactive Re
-
learning
Proactive Re
-
learning
(
periodically
)
{
Waiting Time for load
balancing of mesh network

Figure
3

Re
-
learning Phase Communication



Figure
4

shows the scheme of the re
-
learning phase. It
is a hybrid scheme of both reac
tive learning initiated from
meter and proactive learning initiated from the head

end.
The scheme is pretty simple. When the head end detects
that the meter needs to enter the re
-
learning phase, either
by being notified by the meter or through a periodic
t
imeout, the head end will send a learning start request to
the meter. When the meter receives the request, it will
begin transmitting data until the head end determines that
enough data has been collected and then sends a learning
end request and the new a
pplication table thus ending the
learning session.

The meter sends the re
-
learning requests to the head

end whenever it detects an error in its state table

or has no
initial state table
. It is also impossible for the meter to
detect that an appliance has b
een removed without
analyzing a large amount of data. Such appliances should
be removed from the state table to increase detection
efficiency in the meter. Therefore, it is necessary to
introduce periodic proactive learning into the scheme.

The frequency o
f the proactive learning depends on the
size of the mesh network and the amount of data

that

needs to be transferred
.
Also, it is not necessary to be
sending data 24 hours a day, since off
-
peak hour data may
not

be as useful as peak
-
hour data.

When reques
ting to enter the learning phase, t
he meter
may assign reasoning (a label containing the type of
error) and priority (urgent or not
-
so
-
urgent) for each
detected error and embed these labels into the re
-
learning
request. This would facilitate the head

end
in
coordinating and prioritizing the (re)learning phase of the
entire AMI mesh network

in order to avoid congestion
.
Both the meter and the head

end may intelligently ask
themselves if the error detected is important, since we
only care about those major a
ppliances registered for
load
-
shedding. Therefore, if the errors are caused by
other appliances, which have very

distinct
ive

power
profile
s

from the ones we care, it is reasonable to ignore
those errors.


The additional bandwidth due to this scheme is
negl
igible when not in learning phase. The requests for
re
-
learning can be embedded as a flag in the alive
requests common in most mesh networks. Furthermore,
the additional bandwidth required to conduct learning
phase can be monitored and controlled by the he
ad end
since it tells the meter when to start and stop sending the
learning information. Thus, the scheme is controllable
from the head end and robust.



Clustering Algorithm


The first step in the analysis of the data on the head end
is to establish clus
ters of on and off events in order to
begin to identify what appliances are present in the home.
The clustering algorithm accomplishes this by taking the
days worth of data and grouping like events by their
respective power changes. The pseudo
-
code for thi
s is
shown below:



8

for (each i in eventlist)



// if we are less than our minimum detection throw it away


if ( i < mineventsize)


continue;



// normalize the event


if( i.powerchange < 0)


i.powerchange =
-
1*i.powerchange


i.reacti
vechange =
-
1*i.powerchange


cluster[i].eventList.add(i)


cluster[i].offevents = 1


else


cluster[i].eventList.add(i)


cluster[i].onevents = 1



// search the list


for (each j in eventlist (excluding i))



if ( i.realpower =
= j.realpower +/
-

detection threshold )


cluster[i].eventList.add(j)


eventlist.remove(j)


i.realpower = average of power in the cluster[i].eventList


cluster[i].onevents += 1



else if ( i.realpower ==
-
1 * realpower +
/
-

detection
threshold)


cluster[i].eventList.add(j)


eventlist.remove(j)


i.realpower = average of power in the cluster[i].eventList


cluster[i].offevents += 1



end inner for


end outer for


for (each i in cluster)



/
/ note power events includes both real and reactive


// calculate the average of all power events in i


// calculate the standard deviation of the events in i



return the mean real, reactive power and standard deviations
and how many on/off events o
f each were found



The actual code is

slightly more complicated in order to
look for the actual power change versus reactive but the
idea is the same. The code just gets the first element of
the array, normalizes it, and then searches the rest of the
arra
y for matching events by assigning the first event to a
new cluster. Each time an event is found that matches the
current cluster event; it is removed from the event list and
placed in a list for that cluster item. If the event is also
positive, then the a
lgorithm has found another on event. If
the event is negative, then it has found an off event. The
power value for the current cluster is then averaged again
and used to search the list. That way, the list is searched
for the current average of the events
in the cluster. Lastly,
the algorithm computes the final mean and standard
deviation for use on the meter and in the appliance table
building algorithm. The algorithm also returns how many
times each cluster event was turned on or off during the
collection

period.


Appliance Table Building Algorithm

The most basic appliance model is

the

ON/OFF model
;
h
owever, not all appliances can be explained by just
ON/OFF states.

With the lack of reactive power, it
becomes necessary to utilize the most accurate NILM
pos
sible given the simplified data.
Thus, the finite state
machine (FSM) model
will

be considered
in order
to

increase the

accuracy in describing

appliances that have
multiple states. Algorithms to build FSM are
computationally intensive and thus it’s not rea
listic to run
them on smart meters, but powerful AMI head

ends
will
be able to execute such methods.

We implemented the algorithm proposed in [5][7] with
minor modifications that builds finite state machines
from clusters of edge events based on genetic al
gorithm
and dynamic programming.
The head end code was
written in
Java, and
the
Java Genetic Algorithm Package
(JGAP) [9] was utilized in the implementation of the
genetic algorithm. The overall workflow
of the algorithm
is illustrated in Figure 5

(derived

from [5] with some
modifications). Each step is explained below.



9


Figure
4

Algorithm for Building Appliance State Table


There are two inputs for this program that are obtained
from the results of the edge detection and the clus
tering
of switch events: 1) an array of clusters, and 2) an array of
switch events. Each cluster in the first array is
represented as a tuple {cluster index, power change,
standard deviation}. Here, we are currently using only
real power
to compare the

pow
er change. Each switch
event in the second array is represented as a tuple {time
offset, power change, cluster index}.
The

time offset is
the offset from the first event in seconds, and the cluster
index is the index of the cluster
which is correlated with

the event
. From these two inputs, the program produces
appliance state tables
as was shown above in

t
able
#1
.


Selection of Promising Combinations of Clusters


The first step to build a finite state machine is to select
clusters that represent

the

states
of an appliance. If there
are Nc clusters, then there are 2
Nc

possible combinations
of clusters to select. Each combination can be a candidate
of states of an appliance. Because the number of
combinations becomes huge when Nc is large, it

i
s
impossible to
examine all possible combinations. Thus,
a
genetic algorithm was utilized to select only promising
combinations of clusters. The genetic algorithm creates a
matrix X that has Nc columns where each column
corresponds to a cluster and each row corresponds to

a
candidate appliance. Each element in the matrix is binary,
i.e., 0 or 1. If it is 1, then the corresponding cluster is
considered be one of the states of an appliance. The
maximum number of rows is configurable, and the
genetic algorithm repeats until i
t finds the maximum
number of combinations or it fails to find more promising
candidates. The quality of each row of X was evaluated
simply based on how close the sum of power changes is
to
zero

because state transitions of any appliances should
start and
end with
in an
off state.


Initialization of Finite State Machines


Next, every row of X is used to initialize a finite state
machine. In order to create a finite state machine, the
sequence of power changes must be determined. Because
the number of permut
ations becomes huge when the
number of selected clusters in a row of X is large, the
program put
s

a limit, which is configurable, on the
number of states for an appliance. An example used in [5]
is the combination of 100W, 50W and
-
150W. There are
3! = 6 p
ossible variations of sequence patterns for this
combination, but not all variations are valid because
some variations result in a

negative power valu
e in the
middle of the sequence

which is unacceptable. For
example, if the sequence of power changes is 10
0W,
-
150W, and 50W, then the power value becomes
-
50W
after the second power change. Thus, such variations are
excluded from consideration. Similarly, we also excluded
such variations that result in 0W in the middle of their
state transitions or that don’t

come back to 0W in their
last transitions. The program then selects the best
variation from the valid sequence patterns based on the
frequency with which each sequence pattern occurs in the
observed switch events and the quality criterion defined
in [5].
Here, all observed switch events
included in all

the
clusters each row of X includes are used as the instances
of the power values of the states, and
the
series of the
sequences that maximize t
he quality value are searched
using a

dynamic programming appro
ach. We used two
properties mentioned in [5] for the calculation of quality:
1) the time duration between state changes in a sequence,
and 2) the deviation between the observed power value
and the corresponding value of the cluster (i.e., the
average of al
l power values in the cluster). The target
value of each property is first set to the median of all
linked events, and it is then optimized by repeating the
dynamic programming part of the program until no
further improvement of the value can be achieved.
The
procedures mentioned above are repeated for all rows of
X.


Optimization of Finite State Machines


10

The above procedures create a finite state machine for
each row of X. However, some clusters can be distributed
to different appliances simultaneously whe
n the number
of ones in any column of X exceeds one
.

These

overlaps
must be solved. Thus, the program examines overlap
s for
each column, and if o
verlaps

exist
, it selects the best row
based on the quality value of the best path for each
overlapping applian
ce. The program then recreates
the
finite state machines for the non
-
best appliances without
the overlapped cluster. If the combinations of clusters
cannot produce any valid sequences, then such appliances
are excluded from the matrix X. This procedure is
repeate
d until all overlaps are solved and the algorithm
has assembled the best fit state table which can then be
returned to the meter. Once the table is returned, the
learning phase is then complete.


4.


Prototype Analysis

The prototype was assembled
in order to test the
validity of the above approach. The meter code including
the edge detection and real time monitoring was
implemented
on
an

AVR32 simulator with chip
UC3A0512
. All the head end code was implemented
using Java on a desktop computer in th
e lab. The
prototype was first tested using data taken in the lab using
a (TODO add meter info and specs on lab setup). Our lab
setup is show below in figure #5:



Figure
5

Lab Setup


After the initial testing phase, the prototype

was then
tested on data from two homes. The first home was
monitoring the power usage using a TED 1000. This
meter allowed us to take real power readings every
second and was useful in allowing us to test the full
algorithm from start to finish. The secon
d home measured
data using the TED 5000 which allowed us to add
reactive power tests into our arsenal. Both home collected
data throughout the month of November of 2009. Each
portion of the prototype was first tested individually.
Then the whole system wa
s tested from beginning to end.
The end to end tests were conducted by firs
t running the
learning phase to ascertain the major appliances and then
implementing a policy for the home owner to turn off one
of the big appliances in order to see if our prototy
pe could
detect these policy violations. The results of the testing
are summarized below.


Event Detection


The event detection algorithms were tested on all the
data collected in lab and from site. A typical output
representation is show in figure #6:


Figure
6

Edge detection algorithms


While the above threshold method follows the actual
data much closer, it fails to filter out transient energy
spikes which are unnecessary for the learning phase.
Thus, the step averaging meth
od is preferred in order to
produce fewer data points. A further analysis of the
algorithms along with analysis of bandwidth
considerations is conducted in part five of the paper.

The results showed that the step average method
produced fewer events than t
he above threshold method
mainly due to the added ability for the step average to
filter out spikes in the power signature. Thus, the step
average method was the preferred method of event
detection used throughout the remaining tests.


Learning Phase Test
ing


Clustering


The most important problem that faced the clustering
algorithm was what kind of granularity would exist
between separate edge events. If the distribution of
C2

E2


11

appliance on/off events is uniformly distributed in the
plane of real power, it wo
uld be difficult for the
clustering algorithm to make intelligent decisions based
upon the data. Extensive testing revealed that in the two
test homes, appliances over 1000 Watts seemed to give
enough granularities to be detectable.



Figure
7

Histogram of Events and Clusters



Figure #7
above show a histogram of the number of
detected events at each threshold level for a sample of
data collected from Carl’s house on 12
-
10
-
2009. Notice
that the clustering algorithm takes an averag
e of events
that are separated by a certain threshold of spacing. In this
example, the algorithm created eight clusters based upon
the data and recorded the corresponding number of on/off
events associated with each. This data is then passed on
to the appl
icant table generation code.


It is also important for the clustering algorithm to be
able to hand both real and reactive power. A sample of
generated clusters is shown for a test with reactive power
below in figure #8. Note that the diagram does not show
all found clusters. The algorithm successfully identifies
the first air conditioner represented by the red circles.
Even though the real power values are quite similar, the
reactive power is successful in distinguishing the big air
conditioners shown in gr
een from the smaller ones shown
in red. The clustering also gets numerous smaller
appliances shown by the orange circles. The large
air
-
conditioners had a two stage shut off. Thus, the
clustering algorithm groups the three green and the three
blue separate
ly. These would then need to be identified
during post
-
processing. Finally, it is important to note
that the appliances under 1000 Watts are
indistinguishable because there are just too many of them
uniformly distributed.


Figure
8

Clustering with Reactive Power


Appliance Table Generation

Illustrative Test

As an illustration, the state table generation program
was run on the clustering data as shown above in figure
#7. The results are given below in figure #9. Note that the
appli
cation generating program generates appliances
based upon the greatest clusters of events and thus
disregards the events above 2000 Watts since they do not
carry much weight.



Figure
9

Appliances Detected






Formal Testing

Fi
rst, we tested the appliance table building algorithm
with two manually created inputs.


12

The first
test

was
artificially created in order to test the
algorithm. The
edge events and corresponding clusters
were
fabricated as illustrated in f
igure
10
. Here, th
e labels
on the edges

represent

the power changes of clusters.
From this input, we were able to create two appliance
state tables whose state transitions are illustrated in
f
igure
11
.
The results were exactly as we expected they should
be based on the inpu
t given in figure 10.
This result
demonstrates

that
the algorithm can build state tables for

appliances that have multiple states.



Figure
10

Artificial Data 1 for Testing Appliance
Table Building Algorithm



Figure
11

State Transitions of Appliances Created
from Artificial Data 1


The second
test

was created from the data of the
controlled test conducted at Professor Gunter’s house.
The input e
dge events and corresponding clusters
were
generated as an id
eal representation of the collected data.
The input data is
illustrated in Figure
12
. From this input,
we were able to create five appliance state tables whose
state transitions are illustrated in Figure
13
. These five
appliances are exactly the ones used
in the controlled test.
Here, our program didn’t produce an appliance whose
state transitions were K, D, and B although that pattern
actually appeared in the input. The reason for this is that
D and B belong to other appliances (i.e., a toaster and a
dryer
) whose transitions are C and D, and A and B,
respectively. Because the patterns A and B, and C and D
appeared more frequently than the pattern K, D, and B,
the appliance whose transitions were K, D, and B was
thought to be excluded in the optimization pha
se of the
algorithm that solved the overlaps of the clusters.
Another point worth mentioning is that the program
produced two appliances, an oven 1 and an oven 2, whose
transitions were E and H, and F and G, respectively,
instead of producing one appliance

whose transitions
were E, F, G, and H. This might be because the quality
value of the latter one with 4 states was smaller than those
of the former ones. Another possibility is that the
combination of E, F, G, and H was not selected in the first
place bef
ore the initialization of finite state machines.



Figure
12

Artificial Data 2 for Testing Appliance
Table Building Algorithm



Figure
13

State Transitions of Appliances Created
from Artificial Data 2


Ne
xt, we tested the appliance table building algorithm
with the results of our edge detection and clustering
algorithms against the
real
controlled data. The result is
illustrated in Figure
14
.
In this test, the

dryer and oven 1
seem to be regarded as the sa
me appliance 1. This is
reasonable because the values of power changes of these
two appliances
’ power varied by only 10 W, a too close to
be distinguishable
. Appliance 2 must correspond to an
oven 2, and appliance 3 must correspond to a garage door
opener.

Appliance 4 was created due to random noise that
we being added during the testing by turning off multiple
lights. This random noise is accurately reflected by a 330
Watt appliance.

Unfortunately,

an appliance
corresponding to a toaster was not created. A
ccording to
the log of the program, the edge detection algorithm
mis
-
detected the event represented as K in Figure
12

as
two on events thus
causing
the clustering algorithm
to
mislabel one of the on events
to

around +1500W.
Because of these non
-
ideal input
s, the appliance table
building
algorithm
failed to detect a toaster
. The test

13

illustrated two important points. First, the learning phase
must be longer to pick up all appliances. Second, no
matter what is done, appliances with the same real power
will be

mis
-
classified unless some other form of metric is
used to identify them.



Figure
14

State Transitions of Appliances Created When
Results of Our Edge Detection and Clustering Algorithms
Were Used



Monitoring

TODO: Need some mo
nitoring results here maybe use
carl’s annotated? Not sure just display a simple test
result and some analysis


However, the meter detection is not perfect due to the
complexity of appliances’ power profiles and limited
resources available in the meter.
Fo
r example, at the point
labeled

E1 in Figure X, the meter cannot tell if the dryer
or the first oven is on, because those two appliances have
very close real power consumption.
We also perform
poorly

at the point labeled E2 in Figure X, where we
turned on
and off several lights many times in the house
to generate some background noise. The meter thought
the garage was on at this point due to the missing detailed
profiles of all those lights.



End
-
to
-
end testing results


Two end to end tests were conducted
on the collected
data in order to test the operation of the prototype. First,
monitoring was conducted on Carl’s data and Andrew’s
data in order to ascertain a large appliance to find. For
Carl, we selected his oven. For Andrew, we selected his
air conditi
oner. The following policy is then defined that
neither person should use the identified appliance
between the hours of 6 AM and 9AM and 3PM to
midnight. We then conducted a learning phase on each
subset of data to ascertain a state table and ran the meter

identification code. The results are as follows:


TODO do this test.


5.

Further Considerations


Bandwidth:


One important constraint on the learning phase is the
amount of bandwidth which is available to the meter
when communicating with the head end. A
ssuming the
data was not encrypted, it should take about a 24 byte
payload for meter measurements without reactive power
and a 28 byte payload for measurements with reactive
data. If a meter was required to send all the information
back to the head end, th
en he would require a bandwidth
of 24 or 28 bytes/second and need to send about 2.1 MB
or 2.4 MB per day. While this does not seem excessive,
keep in mind that there are thousand of meters on each
head end communicating through wireless mesh
networks. Thus
, reducing the bandwidth is critical to
make this a viable solution.


Using the data from each of the test homes, the number
of edge events per day was recorded for both the above
threshold event detection and the step average event
detection. The data fo
r the month of November and
December is plotted for Carl’s house in figure #15
-
17.
Note that the amount of data is compressed substantially.
Using the step average technique, the data is always less
than one percent of its original value. Figure 17 shows t
he
number of KB per day which would need to be
transmitted in learning phase.


# Events Per Day
0
100
200
300
400
500
600
700
800
900
1000
11/13/2009
11/14/2009
11/15/2009
11/16/2009
11/17/2009
11/18/2009
11/19/2009
11/20/2009
11/21/2009
11/22/2009
11/23/2009
11/24/2009
11/25/2009
11/26/2009
11/27/2009
---------
12/9/2009
12/10/2009
12/11/2009
Days
# Events
Step Average
Above Threshold

Figure
15

# Events Generated Per Day for Carl’s House



14

Compression Per Day
0.0000%
0.2000%
0.4000%
0.6000%
0.8000%
1.0000%
1.2000%
11/13/2009
11/14/2009
11/15/2009
11/16/2009
11/17/2009
11/18/2009
11/19/2009
11/20/2009
11/21/2009
11/22/2009
11/23/2009
11/24/2009
11/25/2009
11/26/2009
11/27/2009
---------
12/9/2009
12/10/2009
12/11/2009
Days
Compression %
Step Average
Above Threshold

Figure
16

Compression Ratio for Carl’s House


KBPerDayCarl
0
5
10
15
20
25
11/13/2009
11/14/2009
11/15/2009
11/16/2009
11/17/2009
11/18/2009
11/19/2009
11/20/2009
11/21/2009
11/22/2009
11/23/2009
11/24/2009
11/25/2009
11/26/2009
11/27/2009
---------
12/9/2009
12/10/2009
Days
KB
Step Average
Above Threshold

Figure
17

KB Per day for Carl’s House



Figures 18
-
21 show the same types of plots for
Andrew’s data. The compression rate is similar over all
days except on the 8
th

of November. This day had a lot of
activity in the home resulting in a lot of genera
ted events.
While twice the number of events were generated, the
compression rate was still only about 2%. Thus, the total
amount of data to send was still under 6KB. Thus, by only
sending edges the amount of data per meter is reduced in
learning phase to
roughly 1% of the total data content
while still sending enough information to effectively
complete the load monitoring.

TODO add some justification that this is
acceptable

# Events Per Day
0
500
1000
1500
2000
2500
3000
3500
4000
4500
11/3/2009
11/4/2009
11/5/2009
11/6/2009
11/7/2009
11/8/2009
11/9/2009
11/10/2009
Days
# Events
Step Average
Above Threshold

Figure
18

# Events Generated Per Day for Andrew’s Hous
e


Compression Rates Per Day
0.0000%
0.5000%
1.0000%
1.5000%
2.0000%
2.5000%
3.0000%
3.5000%
4.0000%
4.5000%
5.0000%
11/3/2009
11/4/2009
11/5/2009
11/6/2009
11/7/2009
11/8/2009
11/9/2009
11/10/2009
Days
Compression %
Step Average
Above Threshold

Figure
19

Compression Ratio for Andrew’s House


KB Per Day Learning
0
20
40
60
80
100
120
11/3/2009
11/4/2009
11/5/2009
11/6/2009
11/7/2009
11/8/2009
11/9/2009
11/10/2009
Days
KB
Step Average
Above Threshold

Figure
20

KB Per Day for Andrew’s House


Re
-
Learning:

TODO: Add justification that incorrect state
tables can be identified



Identification without re
al power:

TODO: Analyze the robustness of Naoki’s code


15

Basically summarize that we cannot identify
appliances with very similar power signatures


6.

Conclusions and Future Work


Conclusions:

TODO Write this after all tests are done


Future Work:

TODO Write

this

Current ideas:

1.

More testing

2.

Add other metrics to identify appliances perhaps
time of use or amount of time on etc.

3.

We never explored the possibility of using a soft
verification based on whether or not the appliance
responds to a load shed request

4.

Na
oki’s code needs to be expanded to handle
multiple appliances with the same power gracefully

5.

add more as we think of them

R
EFERENCES

[1]

Annabelle Lee

and
Tanya Brewer
,


Smart Grid
Cyber Security Strategy and Requirements
,


Draft

Interagency Report NISTIR 76
28
. [Online].
Available:http://csrc.nist.gov/publications/drafts/nist
ir
-
7628/draft
-
nistir
-
7628.pdf

[2]

Lisovich, M. and
Wicker, S.

Privacy Concerns in
Upcoming Residential and Commercial
Demand
-
Response Systems
.


Proc. of the Clemson
University Power Systems Co
nference

(Clemson,
SC, March,
2008
).h
ttp://www.truststc.org/pubs/332/lisovich200
7pci_v3.pdf.

[3]

Hart GW.

Nonintrusive appliance load monitoring
.


Proceedings of the IEEE 1992;80(12):1870±91.

[4]

M.L. Marceau, R. Zmeureanu, “
Nonintrusive Load
Disaggregation Compu
ter Program To Estimate The
Energy Consumption Of Major End Uses In
Residential Buildings
,


Energy Conversion &
Management
,

Vol. 41, 2000, pp. 1389

1403

[5]

M. Baranski and V. Jurgen,

Genetic Algorithm for
Pattern Detection in NIALM Systems
,


in
Proc.
IEEE In
ternational Conference on Systems, Man and
Cybernetics
, vol. 4, oct 2004, pp. 3462

3468.

[6]

Kwangduk D. Lee, Steven B. Leeb, Leslie K.
Norford, Peter Armstrong, Jack Holloway, and
Steven R. Shaw, “
Estimation of
Variable
-
Speed
-
Drive Power Consumption From
Harm
onic Content,” IEEE Transaction of Energy
Conversion
, 2004. in review.

[7]


Michael Baranski, Jurgen Voss, “
Detecting Patterns
of Appliances from Total Load Data Using a
Dynamic Programming Approach
,”

icdm,
pp.327
-
330,
Fourth IEEE International Conference
on D
ata Mining

(ICDM'04), 2004

[8]

K.H. Ting, Mark Lucente, George S.K. Fung, W.K.
Lee and S.Y.R. Hui
, “
A Taxonomy of Load
Signatures for Single
-
Phase Electric Appliances
,”
IEEE PESC (Power Electronics Specialist
Conference), 12
-
18 Jun 2005, Brazil.


[9]

Java Genetic
Algorithm Package (JGAP), version
3.4.4, 2009. http://jgap.sourceforge.net/

[10]

Michael LeMay, Jason J. Haas, and Carl A. Gunter.
“Collaborative Recommender Systems for Building
Automation”, IEEE Hawaii International Conference
on System Sciences (HICSS 09),Wa
ikola, Hawaii,
January 2009.