# Presentation: 045991

## Data Management Task Team

- Working Group Meeting
- May 11, 2006
- Paul Myrda

## Context

- The models presented are for the following types of applications
- Near Real Time Applications (10’s of milliseconds)
- RTDMS
- Wide Area Angle Separation
- Path / Flow gate - Monitoring / Control
- Inter-area Oscillations
- Historical Applications (about a second or much more)
- State Estimation Enhancement
- Event Analysis
- They are NOT proposed for high speed protection systems

**Notes:**
The near real time applications would require data directly from the PMU.  The PMU or utility PDC would multicast (through the “cloud”) the PMU output data stream to the various locations running the applications either within the source utility or outside the source utility which could be NERC, ISO’s or even another utility.
The historical applications would poll for data from the data historians located at a utility.
All of this is done within approved security policies and procedures

## Current Centralized Model (TVA)

## Current Model Pros & Cons

- Pro’s
- Central model is easier to maintain, monitor and manage
- Synchronizes data for retransmission to data users
- Con’s
- Single point failure
- Introduces additional latency into the real-time system
- Transfers system operating responsibility to third party; no longer source utility responsibility to maintain archives, etc.
- Requires charge back methodology or other means to fund operation (NERC tax?)
- Overall scalability could become an issue.

**Notes:**
The current model has many pitfalls when scaled up.  If there were a 1000 PMU’s coming in to a single center the volume of data would be absolutely huge and the archiving necessary would add significantly to the hardware costs necessary to support the effort.  Also, some utilities may decide that they would do their own archiving (ie, ComEd, AEP and the former METC) all have this model.  So you would end up with duplication of storage and the cost associated with that.  So companies that chose to have their own archive would end up paying more than those that chose not to.  You could imagine other inequities in this type of scheme.

## 3 Basic Models

- Expansion of the current state (TVA Model) that employs centralized data center with an operator (possibly NERC in the future)
- Centralized operator of a “cloud” backbone serving PMU data needs
- Decentralized model the run autonomously but meet security and reliability requirements.

**Note – I think the last 2 items are saying the same thing differently.**

**Notes:**
I really do think that items 2 -3 are identical just said differently.  The decentralized model does require an operator that establishes rules and security measures to ensure proper operability.  Even the Internet has a centralized authority that controls domain names that get uses and also IP address allocations, etc.

## Generalized Data Model

- Data Sources
- PMU
- PDC
- Historians
- Data Sinks
- PDC’s
- Historians
- Applications
- State Estimation
- Stability Augmentation
- Operator Displays
- Reference Node

**Notes:**
This model presents the generalized model for the data.  Think of this as the “stuff” at a utility.  In its simplest form, for a utility with 1 PMU they would still have real time applications and should have an historian to capture the data for future post analysis.  In a more robust environment, where a utility has many PMU’s it makes sense to install a data concentrator just to make communications life easier and probably multiple historians.  Some directly at the substation and also in at a centralized location.  Most large utilities do this today for SCADA data and other information.  AEP and ComEd are 2 that do this today.

## Generalized Interface Model

- Interfaces
- Real-time Streams
- Un-aggregated
- Aggregated
- Historical
- Query, Response, Publish, Subscribe
- ASP (Application Service Provider)
- Web Applications
- Eipp.tva.com/pmuinfo
- Google PMU

**Time Categories**
- Protection (RAS)  - Peer-to-Peer
- Real-time Operations - < 5 sec
-  Driven by system latency
- Event Analysis - Historical

**Notes:**
This model is fairly key in the architecture.  Think of the real-time bus that the PMU is connected to as the communication service (the “cloud”) that gets the “Real Time” PMU data to all of the Near Real Time applications no matter where they reside (inside or outside the utility).  The historian acts as the “bridge” between the Real-Time Bus and the Historical Bus.  No Historian made today can service the needs of Real Time Applications.  They are not designed to do this function.  So this requires the PMU to be Multicast (Broadcast its output to multiple destinations).  This is not a uncommon task in modern communication networks (I am not an expert but they tell me so).
It is important to note that “the Cloud” described here is managed by various entities just like the Internet.  Within the utility it would be managed by the utility (utility staff or contracted out – doesn’t matter) the exterior cloud could be various models of either private or public dedicated carriers, etc.  One solution is an MLPS network that gets leased from the big public carriers or it could be a privately constructed network managed by NERC or.....

## Overall Architecture

**Overall Architecture**

- Reference Bus

- ISO

- RC

- NERC

**Central Services**
- Identification
- Subscription
- Commissioning
- others.......

**Security**

- CA

- Company

- Reference Bus

- Reference Bus

- Data Sources

- Data Sinks

**Notes:**
This is an overall architecture of the “Cloud” or Decentralized model.  Basically, each company (utility) would install the PMUs, necessary communications within the utility, an historian(s) and various applications as they see fit. NERC, ISOs RC, CAs and others would subscribe to the information being provided through an agent running PMU.net (see figure).  PMU.net (Probably NERC) would be the control agency responsible for ensuring security, permissions, naming, etc are in compliance with approved standards.  Just like the domain names on the internet is managed by the Internet Corp. for Assigned Names and Numbers so too this PMU.net would need to be managed.

## Centralized Operator of a “Cloud” Model Pros & Cons

- Pro’s
- Decentralized model does not transfer responsibility to others but instead keeps it with the utility
- Distributed environment reduces the likelihood of a single point of failure.
- No additional latency introduced
- Minimal costs involved to run the control agency.  Mostly administrative and not hardware costs
- Scalability not an issue in the distributed environment
- Synchronizes data for historical applications
- Con’s
- Coordination amongst entities adds its challenges but not uncommon for the industry.

**Notes:**
The “Cloud” model provides many benefits.  The distributed architecture greatly reduces the issue of a single point failure.  I can not imagine a single entity, even NERC, that really needs to monitor 1000 PMUs.  We may need that many to monitor the overall network but not with a single entity.  Even if someone did need that view of the world, the distributed model eliminates the need to the central entity to actually store all the incoming data on a regular basis.  They may buffer data so that they can snapshot an event but a circular buffer that “throws away” old data would be appropriate.  There would be minimal hardware required at the central entity since they are mainly an administrative function.  The hardware burden remains at the supplying utility and through the use of regulations / requirements the need to store the archive data can be imposed as necessary on the utility.  The archive is then distributed across the continent and not in one location.  Even though this data is physically distributed, much like the internet a query (search) for data can respond back with a listing of relevant data points that can then be visually or even physically joined together for analysis.  Just like a search in Google display results from around the globe. The click on a displayed link takes you to the physical server that holds the data.  Throughout all of the scenario, proper security measures are employed.

## Relative Costs

|  | Centralized |  | Cloud model |  |
| --- | --- | --- | --- | --- |
|  | Ops Ctr. | Utility | Ops Ctr. | Utility |
| Administration | $$ | $ | $ | $$ |
| Operating Staff | $$$ | $ | NA | $ |
| Hardware | $$$$$ | $ | $ | $$ |
| Telecom | $$$ | $ | $ | $ |

**Notes:**
I really don’t have a good feel for the actual costs but I did try to illustrate the relative impact of the various components.
I have broken the costs into the following:  
Administration – the people that would be necessary to develop and apply the procedures necessary to run the program.  Things like naming, putting devices in service, generally running the program in an administrative sense.
Operating Staff – these are technical people that know how to run essentially a data center.  These are telecom, database, operating systems, etc. type technicians. 
Hardware – the servers, routers, network attached storage, etc.  The total infrastructure necessary to support the system
Telecom – the communications network needed to support the effort.
I also separated out the PMU.net (NERC – Ops Ctr) managed portion from the utility portion to show that some costs potentially shift from the Ops Ctr. to the utility between the two models.  I did not try to show the initial or Capex outlay separate from the ongoing effort.  The Capex portion could be “converted” to an ongoing cost if one choose to outsource the effort to a hosting center.