Electric Energy T&D - Index

Electric Energy T&D - EEMag March / April 2008 - Index

After a thorough review and discussions of Entergy’s needs, coding
was initiated in 003. The resulting data storage and retrieval system
– called Pegasus RDS TM – was put into service at the first of Entergy’s
regional control centers in 004, and was soon storing data at all four
regional T&D centers and the central transmission operations center.
Since then, the system has been expanded to include a number of
reporting and data analysis tools.
Automation Breeds an Unforeseen Bonus
One of Entergy’s requirements was that the system be maintenancefree,
an unforeseen result of which was the ability of the system to
audit database changes. This feature has been enhanced by adding
a set of reports that allow a user to compare the contents of any two
SCADA databases that have been put into operation since the system
started, providing a complete audit trail of database changes.
Entergy’s Doug Dollar, Project Lead in West Monroe, notes that
this feature has saved his team valuable time. “The new system
provides what SCADA Support Analysts were manually recording into
spreadsheets,” said Dollar. “A review of the report provides a quick
double check that all desired changes have been made correctly.”
[Refer to Figure 1]
figure 1: Pegasus provides a high integrity audit trail of all SCADA object actions via online
screens and exported reports. The system clearly shows old vs. new values when a SCADA
object is modified. In this report example, four analog data points had their Device Type
changed from VCB to XFMR on 8/4/ 007.
All the Data, All the Time
Every alarm, status, analog, analog limit, and accumulator in the
database, including calculated values, is stored by the system.
Because the data is captured periodically rather than by exception,
the load on the EMS host is steady rather than a series of peaks and
valleys that can wreak havoc on system performance. The stability of
the system was proved during hurricanes Katrina and Rita when every
data change and alarm was captured during these times of extreme
system activity.
Included at each site is a fully redundant system that regularly collects
the data from both the primary and secondary EMS machines. The
system takes these two data feeds and decides later which one to
use. [Refer to Figure ] This approach has resulted in no substantive
data losses since the system went into operation, with everything online
and available for use. This data remains available for historical
reference, forensics or other diagnostics long after any event occurs;
i.e., the data is not subject to the “roll-off” that can sometimes happen
with archival systems. The hardware was sized for five years of on-line
storage, but keeping data for longer periods simply requires installing
additional disk capacity and changing one system parameter.
8 I March-April 2008 Issue
figure 2: SCADA measurements are tightly integrated with the EMS information, including
the enabled host, limit pair(s), quality codes and system alarms. The screenshot shows
a typical system failover from node WMSYSA (“System A”) to WMSYSB (“System B”),
identifying data captured where neither node is enabled with the symbols “>> <<”. Also
shown are the actual limit values for one of the displayed analogs.
Moreover, sampling data frequently and storing the median of the
sampled data further enhances analog data reliability. This has the
effect of removing erratic samples and results in a more statistically
accurate representation of the measurement.
No Maintenance Required
To come as close as possible to meeting the zero-maintenance design
goal, it’s necessary to keep track of devices over time, even when
they have name changes. Name changes may occur, for example, if
a Gas Circuit Breaker (GCB) is being replaced by a Vacuum Circuit
Breaker (VCB). The solution is keeping an “invariant key” for each
measurement in the system, and automatically remapping devices to
the keys when a new SCADA database goes online. There is little if
any staff intervention in this process.
Once a new SCADA database is put on-line, the system automatically
stores the contents of the new database and all data collection and
storage applications run though the update without further staff
involvement, handling all necessary re-mapping on the fly. New data
is then available for display, and points with database name changes
automatically return an unbroken set of data across all time stored in
the database. Since there are frequent name changes on the Entergy
system, this feature is invaluable from both maintenance and data
consistency perspectives.