A flexible phasor data concentrator design

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
IEEE TRANSACTIONS ON SMART GRID 1
A Flexible Phasor Data Concentrator Design
Leveraging Existing Software Technologies
Andrew Armenia, Student Member, IEEE, and Joe H. Chow, Fellow, IEEE
Abstract—Recently, many utility companies have been adding
synchrophasor measurement capability to their systems. Syn-
chrophasors can provide operators with additional information
about current system state, and can be used to improve the accu-
racy of state estimation. Currently, many transmission operators
do not have the ability to process, store, and utilize the data from
their own phasor measurement units (PMUs) locally; instead, they
rely on larger data concentrators located elsewhere. We present a
design for a phasor system, called the flexible integrated phasor
system (FIPS), to provide a more flexible, lower cost alternative to
provide independent system operators and transmission owners
ready access to their phasor data. This provides a robust founda-
tion for a variety of smart applications.
Index Terms—Open-source software, phasor data concentrator,
phasor measurement unit, synchrophasor.
I. INTRODUCTION
THE deployment of synchrophasor measurements in power
systems is rapidly expanding. Applications of these mea-
surements are less widespread. Synchrophasors currently are
routed to large data concentrators in central locations. This data
may then be routed back to independent system operators (ISOs)
and transmission owners (TOs) via existing networks such as
those based on the Inter-Control Center Communication Pro-
tocol (ICCP) [1].
Systems configured in this way have considerable commu-
nication overhead, and data storage at the central data concen-
trator is a difficult problem, especially as the number of PMUs
increases [2].
In existing synchrophasor systems, networking issues can
cause data loss. Reliable transport protocols, which detect and
attempt to correct transmission errors, are adopted to combat
this problem. It is important to consider the characteristics of
these protocols. For instance, the Transmission Control Protocol
(TCP) is not well suited for synchrophasor data transmission,
because high latency can occur on lossy links. Other protocols
for improving reliability provide a more robust solution to the
problem of synchrophasor transmission over lossy links.
Efficient storage of synchrophasor data is also important. Ex-
isting databases may require large indexes or considerable time
Manuscript received January 08, 2010; revised February 26, 2010 Current
version published May 21, 2010. This work was supported in part by the Na-
tional Science Foundation under Grant ECS-0622119. Paper no. TSG-00004-
2010.
The authors are with the Department of Electrical, Computer, and Systems
Engineering, Rensselaer Polytechnic Institute, Troy, NY 12180 USA (e-mail:
armena@rpi.edu; chowj@rpi.edu).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TSG.2010.2046509
to extract a subset of the data. A new data storage scheme based
on simple, flat files eliminates these problems.
The problem, therefore, is to develop a system which ad-
dresses these issues. A well-designed phasor system should be
able to receive, share, and store data efficiently, and serve as
a solid foundation upon which synchrophasor applications can
be built. We propose a system, called FIPS for Flexible Inte-
grated synchro-Phasor System, an overview of which is shown
in Fig. 1. FIPS contains communication components, a data-
base, and a data alignment engine, permitting it to function as
a phasor data concentrator. Also, FIPS contains interfaces to
enable the development of applications using the stored and
real-time data.
Synchrophasors and their applications represent a key part
of a future smart grid. Synchrophasors can be used for appli-
cations including dynamic line parameter estimation [3] and
phasor state estimation [4]. FIPS will enable these applications
to be rapidly developed upon a stable base.
II. DATA FORMATS AND CHARACTERISTICS
Most phasor measurement units on the market today use the
IEEE C37.118 protocol for communicating measurements to a
central station [5]. Another similar protocol is IEEE 1344 [6].
Both of these protocols are stateful protocols in the sense that
they require the receiver to maintain information about the data
being sent, and use this information to determine the meaning
of the different fields within a message.
A C37.118 frame contains a number of fields, as shown in
Figs. 2 and 3. All frames consist of certain common fields, such
as a timestamp and status flags.
Data frames contain frequencies, phasors, analog values, and
digital values. Phasors and frequencies are represented as pairs
of 16-bit fixed point or 32-bit floating point values, in either
the rectangular or polar form. Analog values, representing
nonphasor quantities, are also present in the data frame. These
values may also be represented in fixed-point or floating point
formats. Finally, each digital channel consists of 16 bits of
arbitrary data.
Configuration frames contain information required to deter-
mine the meaning of each individual field within the data frame.
Because the number of phasors, analog, and digital channels is
variable, it is necessary to specify the number of each of these
fields in the configuration frame for the data to be successfully
decoded. In addition, the values may be from many PMUs, as
in the case of an output stream from a data concentrator. The
configuration frame indicates if this is the case.
Data processing using stateful formats such as C37.118 can
be challenging, because processing effort must be expended
1949-3053/$26.00 © 2010 IEEE
Authorized licensed use limited to: Sri Manakula Vinayagar Engineering College. Downloaded on May 19,2010 at 11:04:48 UTC from IEEE Xplore. Restrictions apply.

2 IEEE TRANSACTIONS ON SMART GRID
Fig. 1. An overview of FIPS.
Fig. 2. IEEE C37.118 data frame format (simplified).
Fig. 3. IEEE C37.118 configuration frame format (simplified).
parsing the format. Data frames cannot stand alone, as they do
not describe the data they contain. The data must therefore be
combined with data from the configuration frame to be useful.
The data may be transformed to an intermediate format to alle-
viate this issue. Also, this conversion process allows processing
tools to operate on data in many formats, and the output data
may be readily converted to any desired format.
III. DATABASE DESIGN
Within the power system operation domain, synchrophasor
data represents a new challenge in data storage. Data has histor-
ically been sampled and archived at much lower rates, such as
TABLE I
DATA INSERTION RATES INTO MYSQL TABLES
one sample per 4 s in many applications. To accommodate the
high data rate of synchrophasor data, a robust database system
is required.
First, synchrophasor data arrives at a high rate, typically 30
samples per second (sps), but in some cases up to 60 sps. With
many PMUs, and many sampled channels, databases quickly be-
come strained. When certain communication protocols are used,
data may arrive out of order, or with excessive latency. In some
cases, data may be corrupted in transit, and if the communica-
tion protocol or medium is sufficiently unreliable, it may be lost
entirely. The most important of these issues to address is to en-
sure that the database used can achieve a sufficient data rate.
Initially, the open-source MySQL database [7] was tested.
Testing was conducted to verify that an adequate data insertion
rate could be achieved. The results of that testing are shown in
Table I. The testing was conducted on a server with eight 2-GHz
Intel Xeon processor cores, 16 GB of random-access memory,
and a 6-TB array of four 7200-r/min hard disks. The results
show that the system is not very scalable, because even with
a modest number of channels, data tables become full quickly.

ARMENIA AND CHOW: FLEXIBLE PHASOR DATA CONCENTRATOR DESIGN 3
Fig. 4. A well-balanced binary search tree.
Fig. 5. A pathologically unbalanced search tree.
This leads to a large number of data tables, making data access
a complex task.
In MySQL, data tables must be indexed to achieve high per-
formance in data extraction. If the tables are not indexed, the
entire table must be searched to retrieve data matching the de-
sired criteria. This occurs because the data itself is not stored
in an ordered fashion on disk [7]. The indexing makes use of
a class of data structures known as search trees. For example,
let us consider indexing time-tagged data using a simple binary
search tree. In a binary search tree, larger values are placed to
the right and smaller values are placed to the left as the tree
grows. Each node in the search tree contains a pointer to the data
which is indexed by that node. For instance, Fig. 4 represents a
well-constructed binary search tree for a data set. Fig. 5 repre-
sents a pathological case, in which data has been inserted into
the tree in sorted order. The well-constructed tree has a number
of levels on the order of , where is the number of items
in the tree. But in the worst case, the tree actually has levels, in-
creasing the number of operations required to find a given item.
To avoid the worst case, database systems use balancing algo-
rithms [8] to keep the trees balanced. However, these algorithms
add overhead to the insertion of data into the tree.
Other database systems, including PostgreSQL [9] and
Berkeley DB [10], were briefly investigated, but it was de-
termined that a more optimal database could be developed,
starting from the assumption that data will arrive at the database
in an approximately ordered fashion. For data tables with many
columns, only a few of which require indexing, the use of
search trees is practical. But when data arrives in order, and
data records are not large compared to the indexed fields, search
trees create a large amount of unnecessary overhead.
In the proposed database design, data is stored in a single,
flat file per channel, and is buffered for a period before being
written to the database. Synchrophasor data generally arrives
approximately in order, so the buffer only needs to reorder the
few data points that arrive out of order. The data is then written
to the file in a strictly ordered fashion. The scheme for writing
the data to the database is shown in Fig. 6. In the figure, the
dark gray (red in online color version) cell in the queue on the
right represents a missing piece of data. Before the upper gray
cells in the queue can be output to the data file, this dark gray
(red) cell must be filled or discarded. If it is discarded, the data
intended to occupy the dark gray (red) cell cannot be added to
the database later, because the data in the file would then no
longer be in order. If the buffer is made sufficiently large, and
the time before discard sufficiently long, the probability of data
loss can be reduced to a suitably small value.
Once data is in the database, the binary search algorithm is
employed. This algorithm actually operates in a similar fashion
to the binary search tree previously described, but operates di-
rectly on the data. It assumes that the data is already in sorted
order. As can be seen from Fig. 7, a list of data in sorted order
can be treated as if it were the balanced tree in Fig. 4. But when
random access to the stored data is possible, it is unnecessary
to construct or store the actual tree structure to gain the same
performance benefits.
To find data given a timestamp or range, first the data set is
divided in half. The search then proceeds either to the left or
to the right of the split, depending on whether the timestamp
at the midpoint is greater or less than the timestamp sought.
This subset is once again divided in half, and in this fashion, the
search continues recursively until either the desired data point is
found or all points are eliminated. Because the data is repeatedly
divided in half, it can be shown that this search algorithm re-
quires on the order of operations, where is the number
of data points.
IV. COMMUNICATION ISSUES
In developing a phasor measurement network, reliable,
timely communication is of paramount importance. Many
utilities today use multiprotocol label switching (MPLS) virtual
private networks [11], or frame relay circuits [12] to provide
this communication between PMUs and the control center.
These communication media provide a guaranteed bit rate but
are not guaranteed to be error free. Thus, it is important for a
data concentrator to be resilient in responding to errors while
maintaining the ability to provide a low-delay data stream to
real-time applications. If a high degree of reliability cannot be
built into the network upstream of the data concentrator, some
dropped data may need to be tolerated in this stream.
IEEE C37.118 uses a cyclic redundancy check to ensure data
has not been corrupted in transit. However, this does not make
C37.118 a reliable protocol. In the field of communication net-

Fig. 6. Buffering system for data inbound to the database.
Fig. 7. The binary search algorithm. Here, the value 29 is sought.
works, a reliable protocol is one which can make certain rea-
sonable guarantees about data delivery. The concept of layered
protocols provides some relief: IEEE C37.118 frames are typi-
cally not sent directly over a network, but instead are encapsu-
lated within frames of some other protocol. This protocol can
provide the reliability guarantees desired in a given application.
Many networks use simple first-in, first-out (FIFO) queuing
systems. The end systems are assumed to detect congestion in
the network, and react appropriately by reducing the data trans-
mission rate. The bandwidth is divided among various flows,
which are not assumed to have a particular bit rate. Simple FIFO
queuing presents a problem when real-time or constant-bit-rate
(CBR) data transmission is required. CBR sources have some
advantage in queues, because the transmission rate is not de-
creased to accommodate congestion. However, when queues be-
come full, packets are dropped from the tail of the queue. Unless
queues within the network are configured using existing tech-
niques to separately accommodate the CBR data flows, inter-
mittent data loss issues are likely.
If TCP is used to transmit a CBR flow, retransmission ac-
counts for data loss. But TCP implements a congestion window
mechanism to automatically avoid congestion in a FIFO-queued
network [13]. In general, the TCP congestion window follows
a policy known as additive-increase, multiplicative-decrease, il-
lustrated in Fig. 8. When congestion is not detected, the rate
of transmission is gradually increased, as TCP attempts to dis-
cover the maximum capacity of the link. When congestion is
detected, the window size is rapidly decreased to avoid a phe-
nomenon known as congestion collapse [14]. As TCP imple-
mentations have evolved, so have the methods used to avoid
congestion [15]. But TCP does not provide any built-in mech-
anism for priority-based flow control. Thus, high-priority flows
such as synchrophasor data should be identified and marked at
the network edge, and queued separately within the network, to
avoid conflict with other TCP flows sharing the same link. Oth-
erwise, when the congestion window is reduced, the TCP buffer
is likely to overflow due to the constant input rate.
Because communication links must be appropriately provi-
sioned and engineered to provide congestion-free flow of syn-
chrophasor data, the congestion-avoidance portion of TCP rep-
resents additional overhead. This overhead may be avoided by
the use of protocols other than TCP. For instance, the User Data-
gram Protocol (UDP) [16] allows for the simple transmission of
packets over the communication medium. However, UDP does
not provide for guaranteed reliable delivery.
The Real-time Transport Protocol (RTP) can provide further
improvement. Consider that a typical PMU data frame con-
sisting of 10 phasors and 10 analog values is 120 B. Added to
this is a minimum 20-B IP header and a minimum 20-B TCP
header. This represents an overhead due to headers of 33%. RTP
supports a form of header compression [17] which enables the

Fig. 8. TCP behavior on a lossy link.
header overhead to be reduced to 2 B. In remote locations, where
bandwidth is scarce, this savings could enable synchrophasor
streaming where it was previously impossible. But RTP still
does not provide reliability in the event of bit errors or other
packet losses.
To provide for resilience in the face of errors, a “selective re-
peat” protocol for reliable, real-time data transport may be used.
In this protocol, data is sent as datagrams using UDP. The sender
does not wait for acknowledgements from the receiver, but in-
stead maintains a large buffer of previously sampled data. While
data arrival is not guaranteed, the sender need not be concerned
with this fact. The receiver can detect, based on timestamps or
sequence numbers, when data has been lost, and request that the
sender retransmit data from its local storage. Many PMUs al-
ready support local data storage, so implementation of this pro-
tocol should not be difficult. This protocol may also be imple-
mented by connecting the PMU over a high-reliability link to an
intermediate system.
Of course, no communication protocol can provide re-
dundancy if the physical medium is damaged, e.g., an errant
backhoe destroying the fiber. Redundant communication links
may be built into the network to provide additional reliability.
Ideally, physical-layer redundancy schemes would be em-
ployed. For instance, the same signal may be sent down two
separate optical fibers or wires. The receiver may then choose
the stronger signal, providing redundancy against transient
noise and physically damaged media.
V. SIMPLE PHASOR STREAMING PROTOCOL
The Simple Phasor Streaming Protocol (SPSP) is a protocol
developed for the transmission of data which is tagged in both
time and space dimensions. The protocol data unit is a time-
tagged data frame which contains tagged data values in a variety
of different formats. SPSP data frames can be transported using
a variety of underlying protocols, such as UDP or RTP, or a
custom protocol for reliable transport as described previously.
In FIPS, this protocol is used within a given node to avoid the
need to deal with disparate, possibly complex protocols within
each system component. It may also be used as a protocol for
communication between FIPS instances at different locations.
Fig. 9. SPSP protocol data unit format (simplified).
The protocol has been designed for ease of data concentra-
tion. It is simpler to process than protocols such as IEEE C37.
118, due to the fact that all data arrives with both time and lo-
cation tags. In existing protocols, more complex parsing and
additional state information is required to determine the spe-
cific measurements contained within a protocol data unit. In the
C37.118 protocol data frame shown in Fig. 2, phasors, analog,
and digital values are not tagged with unique identifiers. Their
significance is given only by position within the frame. This has
the advantage of saving a small amount of bandwidth. Once data
reaches the data concentrator, speed of processing is of greater
concern. Therefore, the SPSP data frame tags each value with
a channel identifier, as seen in Fig. 9. IEEE C37.118 has the
ability to transmit human-readable channel identifier informa-
tion in configuration frames, such as the one in Fig. 3. But this
data is of little use to a data concentrator. Thus, manual con-
figuration is required. The use of the intermediate SPSP pro-
tocol eliminates the need for this manual configuration within
the core of the data concentrator. If used to transmit data be-
tween data concentrators, and care is taken to avoid overlap in
channel IDs, it also eliminates the need for manual configura-
tion of those communication channels.
VI. TIME ALIGNMENT
One function of a data concentrator is to align data in time.
This consists of forming data packets with a given timestamp,
and assembling all data received with that timestamp into a
single packet. The basic algorithm is simple: construct a new
frame when the first frame with that timestamp is received.
Then, as additional frames with the same timestamp arrive,
combine them with the first frame. Once a certain time expires,
or all the data is received, transmit the frame, then ignore any
additional frames with timestamps less than or equal to that of
the frame just sent.

Fig. 10. A listing of events in the database.
A configurable parameter is the time delay between the first
data arrival and the frame’s transmission. By varying this pa-
rameter, a shift is made from low delay to high reliability. Thus,
assuming the data concentrator has sufficient throughput capa-
bilities and negligible processing delay, in an unreliable network
the data concentrator cannot improve latency without impacting
reliability. Improving both of these desired attributes simultane-
ously requires improvements at the lower levels of the system.
The time alignment algorithm can be easily adapted to handle
inbound streams of different data rates. In this case, the algo-
rithm must be aware that certain channels will not be represented
in all data frames. Also, if the output is to be in the C37.118
protocol, data must be resampled, since C37.118 does not allow
some values to be missing from a frame. If output is to be in
SPSP format, as in FIPS, the data need not be resampled at the
time-alignment phase. Only the data expected for a given time-
stamp will be sent. A conversion stage can handle resampling
tasks if this SPSP stream is to be converted to another protocol.
This conversion stage may either downsample by simple deci-
mation, resulting in minimal delay, or attempt to upsample and
interpolate the missing data points from slower channels. The
specific design of these resampling algorithms is outside the
scope of the phasor system design.
VII. USER INTERFACE
A data concentrator should provide a flexible user interface
with the ability to perform many functions. A user interface
has been developed which provides this flexibility in a number
of important ways. By using the open-source Ruby on Rails
model-view-controller framework [18], the user interface is in-
dependent of the means used to store the data, and new func-
tionalities can easily be added simply by implementation of new
views and controllers which access the data in the model layer.
Data can easily be exported in multiple formats, visualization
tools are available to show PMU data geographically or on tra-
ditional plots, and users can easily see an inventory of available
PMUs and measurement channels. For example, Fig. 10 shows
a listing of disturbance events stored in a database, and Fig. 11
shows PMUs in the database on a map, using the Google Maps
API [19]. Note that only a subset of existing PMUs is shown in
the figure.
In addition, the framework allows controllers to be developed
which expose an interface to external applications. By accessing
specially formatted addresses on the data concentrator, applica-
tions may authenticate with the system and request data from a
given measurement channel in a number of formats. This inter-
face can be accessed by code written in any language which has
support for the HTTP protocol.
VIII. PHASOR GATEWAYS
The North American SynchroPhasor Initiative (NASPI) has
proposed a concept known as NASPInet [20], which represents
a peer-to-peer architecture for the distribution of phasor data.
NASPInet consists of an entity called a data bus to which phasor
gateways are connected. These phasor gateways communicate
with each other to exchange data on an as-needed basis.
FIPS can provide the functionality of a phasor gateway with
the addition of a few network services. First, a service must be
provided to allow access to metadata, such as channel identi-
fiers. Remote access must be available to data stored in the data-
base, and a means to stream real-time data as it is received is
also necessary. A system for authentication of remote systems
is necessary. But these functionalities are straightforward to im-
plement given a robust foundation.
An example network topology for peer-to-peer data sharing
is shown in Fig. 12. The FIPS server at the top of the diagram
might be located at a large regional control center such as an
ISO. The servers at the bottom might be located at transmission
owners. All data is routed through the MPLS links to the central
location, and the router at that point must transfer data between
the two TOs, if that is desired.
When operating as a phasor gateway, the possibility of mul-
ticast for data transport should be considered. Multicast, as the
name suggests, permits data to be transmitted from one source
to many receivers. Furthermore, with network-layer multicast,
the replication of data occurs within the network elements, re-
ducing the bandwidth requirements at the network edges. It is
conceivable that a phasor stream will be distributed from one
source to many destinations, and bandwidth can be conserved
by the use of multicasting. In MPLS networks, multicasting can
occur at the service provider level, reducing the level of traffic
leaving any endpoint [21]. Fig. 13 shows the network topology
with network-layer multicast. Data being exchanged between
the TOs is no longer required to travel twice through the MPLS
network.
Data sharing is one of the basic goals of the FIPS system.
When data is being shared via communication networks, secu-
rity is of concern. Public networks such as the Internet provide
no guarantees of security, and malicious attackers may be able
to intercept or tamper with data if cryptographic techniques are
not employed.
Security concerns are especially important in the multicast-
based network described above. The most important security
concern in synchrophasor measurement is data integrity: en-
suring that no attacker is able to pose as one of the authorized
entities in the system. This can be achieved with a number of
widely known asymmetric encryption algorithms. One such al-
gorithm is RSA [22]. In these schemes, every data source has
a secret private key. This key has a corresponding public key.

Fig. 11. A map generated from the PMU database.
Fig. 12. An MPLS network topology for simple peer-to-peer data sharing.
These keys may be considered as mathematical functions and
such that , but that it is not easy
to determine from and , or and , that is,
Fig. 13. MPLS network topology with network-layer multicast.
and are not easily invertible. (In fact, the keys are large nu-
meric parameters to more general functions, but therefore the
simpliﬁcation in notation used here can be made without loss of
generality.) Note that and must be invertible by deﬁnition,

since and , but knowledge of should
not yield information about and vice versa. Most algorithms
in use generate and as a pair. Generally, one key is made
public, and is assumed to be widely known and distributed. The
other is kept a secret, and is not divulged to anyone other than
the entity which created it.
As an illustration, using the nomenclature customary to cryp-
tographic discussions, suppose Alice generates a pair of keys
and . Alice keeps a secret, but publishes her key .
If Bob wishes to send a message to Alice, he should find
Alice’s function from a trusted source. Then, he can transmit
to Alice, confident that even given the public knowledge
of , no one other than Alice is able to decrypt the message.
Since Eve (an eavesdropper) cannot compute as ,
the encrypted message is secure. Similarly, Alice can prove her
identity to Bob by sending a message as . If the value
represents a sensible message, it can be concluded
with some reasonable probability that Eve could not have gen-
erated the message.
There is a catch: Eve can construct her own key pair and
and try to convince Bob that is really Alice’s . Then
Eve can receive the message, compute , then
send onward to Alice, and intercept the message without
Alice or Bob knowing of the interception. Also, Eve can send
forged messages to Bob. This is referred to as a man-in-the-
middle attack. To prevent this attack, it is clearly very important
to ensure that the users of cryptographic keys obtain them only
from trusted sources, such as their original creators, and only
obtain them through trusted communication channels, such as
an in-person exchange.
Asymmetric encryption algorithms typically represent con-
siderable overhead. Therefore it is not desirable to evaluate
or where consists of a large amount of data.
One-way functions, or hashes, are used to avoid this problem.
A hash is a function which returns a fixed, short, unique
representation of . should satisfy a few properties: it
should be difficult to compute a value of for which
is equal to some known value . It should also be unlikely
that for two different inputs and . Finally,
should be fast to compute relative to or .
Given this function, we need only to compute , not
, to create proof that the data originated from an authentic
source. The receiver computes and and
compares them, with knowledge of the correct function for
the authentic source. Given the properties of , and ,
it is very difficult for an attacker to construct a value such
that —the necessary condition to have a
receiver accept false data.
In the event that data confidentiality is required, another cryp-
tographic scheme can be adopted. In a multicast medium, the
same encrypted data must be sent to all receivers, but it is de-
sirable to allow the data to be decrypted by a set of many keys.
To accomplish this goal, the data can be encrypted with a sym-
metric encryption algorithm, whose inverse
is easily computed given the single key. An example
of such an algorithm is Blowfish [23]. This key may be gen-
erated randomly and used for only a short period before it is
changed. Then the key is encrypted successively using the
public key of each authorized receiver, and transmitted as
a key block. The key block thus contains a series of encrypted
keys: Each receiver may attempt to
decrypt the key using its private key . If the receiver is autho-
rized to decrypt the data associated with the key block, one of
these decryptions will be successful. Once the key is obtained,
the receiver may decrypt the multicast data. Any receiver may be
deauthorized the next time the symmetric key is changed simply
by not including that receiver’s key in the next key block.
It is important to note that a detailed cryptographic analysis of
these cryptographic strategies has not yet been conducted, and
that the authors may not be aware of all possible attacks against
them. They are presented here for illustrative purposes. While
the underlying algorithms are generally well-tested, minor im-
plementation errors can result in large security issues. Before
being implemented in a production system, the techniques de-
scribed in this section should be subjected to additional scrutiny
and review by experts in the field of cryptography.
IX. CONCLUSION AND FUTURE WORK
FIPS will provide an important building block in a future dis-
tributed synchrophasor measurement system. It provides many
of the attributes of an ideal phasor processing system in a co-
hesive, integrated form. It is important to continue to consider
communication issues when new PMUs are being installed. An
FIPS pilot deployment is planned at ISO New England in June
2010.
ACKNOWLEDGMENT
The authors would like to acknowledge the support of the RPI
Power System Research Consortium Industry Members: AEP,
FirstEnergy, ISO-NE, NYISO, and PJM. The authors would also
like to acknowledge the FNET project at Virginia Polytechnic
Institute, and J. R. Carroll and P. Trachian at the Tennessee
Valley Authority, who have provided us with data for testing
purposes. We would also like to thank M. Shukla, X. Luo, and
D. Bertagnolli of ISO New England for providing a list of distur-
bance events, and L. Vanfretti for providing input and assistance
with data collection.
REFERENCES
[1] IEC 60870-6/TASE.2: ICCP, IEC Standard 60870-6-802, 2005.
[2] J. Zuo, R. Carroll, P. Trachian, J. Dong, S. Affare, B. Rogers, L. Beard,
and Y. Liu, “Development of TVA SuperPDC: Phasor applications,
tools, and event replay,” in Proc. 2008 IEEE Power and Energy Soc.
General Meeting—Conversion and Delivery of Electrical Energy in the
21st Century, Jul. 2008, pp. 1–8.
[3] D. Shi, D. Tylavsky, N. Logic, and K. Koellner, Identification of Short
Transmission-Line Parameters From Synchrophasor Measurements
Sep. 2008, pp. 1–8.
[4] L. Vanfretti, J. Chow, S. Sarawgi, D. Ellis, and B. Fardanesh, A Frame-
work for Estimation of Power Systems Based on Synchronized Phasor
Measurement Data Jul. 2009, pp. 1–6.
[5] IEEE Standard for Synchrophasors for Power Systems, IEEE Standard
C37.118, 2006.
[6] IEEE Standard for Synchrophasors for Power Systems, IEEE Standard
1344, 1995.
[7] “MySQL 5.0 Reference Manual,” Sun Microsystems Inc., 2010 [On-
line]. Available: http://dev.mysql.com/doc/refman/5.0/en/index.html
[8] L. J. Guibas and R. Sedgewick, “A dichromatic framework for balanced
trees,” in Proc. 19th Annu. Symp. Found. Comput. Sci., Oct. 1978, pp.
8–21.

[9] PostgreSQL Documentation, PostgreSQL Global Development Group,
2009 [Online]. Available: http://www.postgresql.org/docs/
[10] Oracle Berkeley DB. Oracle Corp. [Online]. Available: http://www.or-
acle.com/technology/products/berkeley-db/index.html
[11] E. Rosen, A. Viswanathan, and R. Callon, RFC 3031: Multiprotocol
Label Switching Architecture 2001 [Online]. Available: http://www.
ietf.org/rfc/rfc3031.txt
[12] T. Bradley, C. Brown, and A. Malis, RFC 1490: Multiprotocol Inter-
connect Over Frame Relay 1993 [Online]. Available: http://www.faqs.
org/rfcs/rfc1490.html
[13] M. Allman, V. Paxson, and W. Stevens, RFC 2581-TCP Congestion
Control 1999 [Online]. Available: http://www.ietf.org/rfc/rfc2581.txt
[14] V. Jacobson and M. J. Karels, Congestion Avoidance and Control 1988.
[15] K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno,
and SACK TCP,” Comput. Commun. Rev., vol. 26, pp. 5–21, 1996.
[16] J. Postel, RFC 768—User Datagram Protocol 1980 [Online]. Available:
http://www.ietf.org/rfc/rfc768.txt
[17] S. Casner and V. Jacobson, RFC 2508—Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links 1999 [Online]. Available: http://
www.ietf.org/rfc/rfc2508.txt
[18] D. H. Hansson, Ruby on Rails: Documentation 2010 [Online]. Avail-
able: http://rubyonrails.org/documentation
[19] Google Maps API Google Inc., 2008 [Online]. Available: http://code.
google.com/apis/maps/
[20] Y. Hu, Data Bus Technical Speciﬁcations for NASPInet 2008.
[21] B. Yang and P. Mohapatra, “Multicasting in MPLS domains,” Comput.
Commun., vol. 27, pp. 162–170, 2003.
[22] R. L. Rivest, A. Shamir, and L. M. Adleman, “Cryptographic Commu-
nications System and Method,” U.S. Patent 4 405 829, Sep. 20, 1983.
[23] B. Schneier, “Description of a new variable-length key, 64-bit block
cipher (blowﬁsh),” in Fast Software Encryption, Cambridge Security
Workshop Proc., Dec. 1993, pp. 191–204.
Andrew Armenia (S’08) received the B.S. degree in electrical engineering and
computer and systems engineering from Rensselaer Polytechnic Institute (RPI),
Troy, NY, in 2008. He is currently working toward the M.S./Ph.D. degrees in the
Electrical, Computer, and Systems Engineering Department at RPI.
His interests currently include computer networking, database systems, and
power systems.
Joe H. Chow (S’72–M’78–SM’84–F’92) received the M.S. and Ph.D. degrees
from the University of Illinois, Urbana-Champaign.
After working in the General Electric Power System business in Schenec-
tady, NY, he joined Rensselaer Polytechnic Institute, Troy, NY, in 1987. He
is currently a Professor of Electrical, Computer, and Systems Engineering and
the Associate Dean of Engineering for Research and Graduate Programs. His
research interests include multivariable control, power system dynamics and
control, voltage-sourced converter-based FACTS Controllers, and synchronized
phasor data.

A flexible phasor data concentrator design

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (12)

Similar to A flexible phasor data concentrator design

Similar to A flexible phasor data concentrator design (20)

A flexible phasor data concentrator design