**EIPP Data Management Task Team Architecture**

**Abstract**

The Eastern Interconnection Phasor Project is advancing the state of the
art in power system monitoring and shares information deemed to be
valuable in enhancing the reliability of the bulk power grid. Within the
project various teams have been assembled to address activities
essential to the successful deployment of the project. One of the teams
is the Data Management Task Team. This paper will describe both the
current and future states of data management and especially how the
future state will support the long term vision of the EIPP that calls
for delivering value within the operations environment using new
inter-regional information and measurement systems.

> .

**1. Introduction**

The work of the EIPP is carried out in six Task Teams with coordination
and guidance from a Work Group consisting of over 220 interested
stakeholders. Each of the Task Teams is led by an industry member with
support from a DOE-funded CERTS team member. The Task Team leads along
with NERC, CERTS and DOE representation form a Leadership Committee that
acts to facilitate communication and coordination among the project team
members \[1\]. This paper will focus on the work of one the teams, the
Data Management Task Team. Specifically, we will present both the
current and proposed future architecture that will support the EIPP data
transfer, synchronization, references and archiving.

**2. Existing Architecture**

Within the EIPP, each participating organization sets its own
requirements for data management and handling. To support the EIPP
endeavor the Tennessee Valley Authority (TVA) has made a substantial
investment in developing a centralized EIPP Phasor Data Concentrator,
called a "Super

PDC", and have set up a comprehensive database of phasor measurements.
The initial objectives for the Super PDC were simple. First and foremost
the project team wanted to create a system with an open and completely
scalable architecture that specifically supported the most popular
phasor data transmission protocols, in particular: PC37.118, IEEE1344,
the BPA PDCstream and Ole for Process Control (or OPC).

![](media/image1.wmf){width="3.0256944444444445in"
height="2.2805555555555554in"}

Figure 1 -- Existing Architecture

In the current working implementation of the Super PDC, all of these
transmission protocols have been developed. The project team has tested
and deployed IEEE1344, PDC stream and OPC. Additionally, the C37.118
protocol is currently being tested with several different PMU vendors.

**3. Improving the Architecture**

Recently, the data management task team has been working to develop an
architecture that will support the transition of the EIPP from a
research project with useful operational characteristics into a highly
robust, fault tolerant, and scaleable information system that can be
used in mission critical aspects of power system operations (as input to
state estimators and network security analysis applications for
example). Such an architecture will enable the EIPP to evolve into a
North American Phasor Data Network (NAPDN) if desired.

Any good architecture needs to be derived from a solid set of
requirements. Other EIPP working groups are developing these
requirements more formally, but the data management task team has
identified several key system elements that have led to an initial
proposal for the new architecture. Those requirements have led to
identifying a need for the following standardized interfaces:

-   Aggregated real-time phasor data stream input

-   Un-aggregated real-time phasor data stream input

-   Aggregated real-time phasor data stream output

-   Historical database query / response, publish / subscribe interface

-   Web based application interfaces

These interfaces are designed to allow applications that can benefit
from phasor measurement data -- both real time and historical -- to have
a well defined method of obtaining that data from several points within
the overall NAPDN. Figure 2 illustrates the overall architecture.

![](media/image2.wmf)

Figure 2 -- NAPDN Architecture

The overall network topology is a hub and spoke type design. The hub is
represented by the element labeled the Distributed Phasor Data
Repository (DPDR). This entity is actually a distributed computing /
communications environment that is geographically dispersed but still
serves as the hub for the purposes of this architecture. The spokes
leading away from the hub terminate at Corporate Entities (CE) which
represents the end users and producers of phasor measurement data.

Figure 3 drills down into the DPDR to reveal its underlying topology.
The DPDR consists of three corporate entities which all receive,
maintain, and replicate all of the real time phasor data streams and all
historical data. Each of these corporate entities exposes several
identical interfaces that provide access to the data products as well as
necessary management applications to maintain the DPDR itself.

![](media/image3.wmf){width="3.027083333333333in"
height="2.0854166666666667in"}

Figure 3 -- Distributed Data Repository

Each Corporate Entity (CE) has the same architecture and interfaces
whether they are part of the DPDR or are at the end of a spoke as a
client. Figure 4 illustrates the CE architecture and interfaces. Each CE
maintains one or more Phasor Measurement Units (PMU), a Phasor Data
Concentrator (PDC), a local data historian, and one or more
applications.

![](media/image4.wmf){width="3.782638888888889in"
height="1.9555555555555555in"}

Figure 4 -- Corporate Entity Architecture

The externally visible interfaces are very similar to those at the DPDR
level and include:

-   Aggregated real-time phasor data stream input

-   Un aggregated real-time phasor data stream input

-   Aggregated real-time phasor data stream output

-   Historical database query / response, publish / subscribe interface

These interfaces allow the CE to act as either a simple client and
supplier of PMU data to the CM, or to act as one of the constituent CEs
of the DPDR itself. When a CE acts as part of the DPDR, the same
interfaces and internal actors (PDC and historian) are used to maintain
a replicated image of the real-time phasor data stream and historical
data for the entire network. The architecture is the same for all CEs,
but the network and data management elements would be sized
appropriately to handle full data set.

Figure 5 illustrates the standardized interfaces to the individual
components (actors) that make up a CE. All of these interfaces are the
same as those defined previously. The strength of the architecture lies
in its use of a small number of well defined interfaces based on
international standards. The interfaces are the same in each of the
entities in the architecture but they are used differently and have
different capacity requirements depending on where they lie in the
hierarchy.

This high level architectural proposal is intended to provide a vehicle
for discussion. As the discussion evolves, more complete architectural
renderings, use cases, interface descriptions, message requirements, and
other architectural elements must be developed and documented. In
particular, the formal requirements being developed by other EIPP teams
must be supported by relevant use cases, analyzed, and then mapped to
appropriate technologies that will be used to implement the
architecture.

![](media/image5.wmf){width="2.2194444444444446in"
height="3.8513888888888888in"}

Figure 5 -- CE Component Actors and Interfaces

**4. Message Architecture Design Options**

The previous section described a vision for the high level conceptual
architecture for the NAPDN. The data management team has done some
preliminary investigation into some of the details of how the interfaces
described earlier might be implemented and the messaging architecture
that might be capable of supporting it.

**5. Reference Implementation**

In an effort to bring this design "down to earth" and explore
implementation issues, a reference architecture is under development. A
publish / subscribe architecture has been chosen due to its many
successful implementations and demonstrated scalability by various
vendors including BEA ([www.bea.com](http://www.bea.com/)), Tibco
([www.tibco.com](http://www.tibco.com/)) and IBM
([www.ibm.com](http://www.ibm.com/)). As you can see from figure 6, the
collective capability of a set of publish / subscribe message brokers
can implement a single CM or even support a federated CM model.

![](media/image6.wmf){width="3.0284722222222222in" height="2.04375in"}

Figure 6 - Set of publish/subscribe message brokers

Publish / subscribe is a style of messaging application in which the
providers of information (publishers) are decoupled from the consumers
of that information (subscribers) using a broker. In a publish /
subscribe system, a publisher does not need to know who uses the
information (publication) that it provides, and a subscriber does not
need to know who provides the information that it receives as the result
of a subscription.

Utilities, Super PDC's, regulatory organizations can publish their
phasor information to the CM cloud without a concern as to how the data
is replicated and can browse/subscribe to the information by topic.

**6. Topic Trees**

It is important to separate the actual phasor data from the metadata
that describes the phasor streams. Such metadata will include
information about the sponsoring utility, bus monitored, voltage,
substation, location, protocol, query capability and sensor
characteristics for example. Typically a message broker implements a
Topic Tree that is a hierarchy of the metadata that will be used for
browsing / subscribing. Wild cards can be used in a metadata query to
determine the available PMU streams. This metadata tree can initially be
configured with a few key nodes but can be extended indefinitely as
utilities implement / publish additional PMU's. These publications can
be forwarded immediately to current subscribers, retained indefinitely
or expire some time in the future. A typical topic tree might be a
geographic tree such as:

![](media/image7.wmf){width="2.827777777777778in"
height="1.3159722222222223in"}

Figure 7 -- Topic Tree generic example

Each character string in the figure represents a node in the topic tree.
A complete topic name is created by aggregating nodes from one or more
levels in the topic tree. Levels are separated by the "/" character. The
format of a fully specified topic name is: "root/level2/level3".

The valid topics in the topic tree shown above are:

> "USA"
>
> "USA/Alabama"
>
> "USA/Alaska"
>
> "USA/Alabama/Auburn"
>
> "USA/Alabama/Mobile"
>
> "USA/Alabama/Montgomery"
>
> "USA/Alaska/Juneau"

In defining a phasor Topic Tree it is important to identify relatively
stable topic nodes. With all the mergers and acquisitions in the utility
industry a company name and corporate affiliation can be volatile.
Fortunately, transmission assets are firmly anchored in the dirt
(physical location) and their voltage is fixed based on the transmission
infrastructure deployed. So a proposed stable Topic Tree could be:

![](media/image8.wmf){width="2.076388888888889in"
height="2.8256944444444443in"}

Figure 8 -- Phasor Topic Tree Example

Such a structure would allow a subscriber to browse / identify the
phasor measurement by region, voltage, substation or bus. The data level
could provide metadata (Information) about the actual utility, company,
latitude / longitude, equipment manufacturer, date of publish / update,
author or other pertinent information about the measurement. The other
data nodes could provide an actual stream of data in response to a query
(History query from a historian) or URL/links to the actual PMU data
streams.

**6. Conclusions**

The Data Management Task Team has evaluated the existing Super PDC as
well as other relevant architectures and has established a proposed
future architecture that will support the EIPP data transfer,
synchronization, references and archiving. They have evaluated the known
requirements for data management and handling. The data management task
team has identified several key system elements that have led to an
initial proposal for the new architecture. These include: aggregated
real-time phasor data stream input, un-aggregated real-time phasor data
stream input, aggregated real-time phasor data stream output, historical
database query / response, publish / subscribe interface and web based
application interfaces. The group has also recommended a reference
architecture and also introduced the concept of Topic Trees to manage
the storage and retrieval of the data and metadata. The group still has
significant work to complete within the EIPP but is well on its way to
establishing a solid model for the other working

**7. References**

\[1\] Eastern Interconnection Phasor Project Donnelly, M.; Ingram, M.;
Carroll, J.R. System Sciences, 2006. HICSS \'06. Proceedings of the 39th
Annual Hawaii International Conference on Volume 10, Date: 04-07 Jan.
2006.