Substation Functional Analysis and Diagnostics Database
Guest article by
William J. Ackerman, ABB
July 2002
Substation operation and maintenance
requires a clear and complete knowledge of control and operational
characteristics in real time. That
is, every characteristics and ‘location’ of every functional aspect must be
easily identifiable at any time.
In older substations, with all
electromechanical devices and indicating lights and meters, the location of
functions was unambiguous. That is, physical panels were identified with a particular
circuit breaker or transformer; and all control and indication functions related
to that device were clearly identified.
In newer substations equipped with
Intelligent Electronic Devices, the ‘location’ of a particular function may
move between physical devices depending on real-time or other conditions.
For example, the active recloser control for a circuit breaker might be
located in one of several IEDs, or perhaps a physical switch, or remotely via a
SCADA system.
As the industry moves to more
intelligent devices in the substation, such as UCA-2.0TM or
IEC-61850-compliant devices, the physical devices involved in any given function
tend to become even less obvious.
The solution to this problem will
have to be provided by application programs that access a database and provide
required information to a large and varied class of users.
The program might be called a ‘substation visibility’ tool.
Such application programs will require access to a dynamic database that
contains the basic configuration and functional location information.
Note that this database can be centralized or distributed, or some
combination of both.
The
purpose of this document is to describe the basic requirements of such a
database, and provide guidance to the designers of new protocols and IEDs
Types of devices and database requirements
It is convenient to
group the equipment in a substation into three basic types:
- Electromechanical
or static devices with no or extremely limited communications capability.
This would include such devices as electromechanical relays, lockout
switches, lights, meters, other indicators, etc.
These devices would have to be identified in a ‘static’ database
that describes their features and functions.
Basically, it is assumed that there would be modest maintenance
requirements for such a database, and that any time the function or feature
of a device is added, deleted or modified, the local (i.e., in the
substation) database would have to be updated.
- Current
generation IEDs, such as microprocessor relays, that have the ability to
transmit varying degrees of functional and real-time information.
This information could include, for example, primary and backup
protection functions that are currently active, current status of controlled
equipment (open, closed, enabled, disabled, etc.) metering data and
connectivity, to list a few.
Because of the varying capabilities of these IEDs, it is likely that
the substation database will consist of a combination of static (i.e.,
maintained by external means) and dynamic elements.
The dynamic elements would be retrieved from the IED at the time the
substation visibility program is initiated.
It is a requirement that the dynamic information be updated in real
time as needed.
- Next
generation IEDs, such as those that are, or will be compliant with UCA-2.0TM
or IEC-61850, that can have the ability to supply all required information
whenever requested.
In effect, the database relating to these IEDs can be considered to
be ‘distributed’.
Objectives
of the “Substation Visibility” Database
The Substation
Visibility program should be designed to support multiple activities related to
the operation and use of equipment in a substation.
Basically, the objective is to enable real-time monitoring and control of
the substation equipment and IEDs. In
order to do so, a ‘cross reference’ of functions and the physical devices
that are currently enabled to perform such functions must be provided.
Functions
that may be performed by the Substation Visibility program can include the
following:
- Identification
of intentional migration or backup of functions
(e.g., data substitutions, alternate sources, backup protection,
etc.)
- Identification
of unintentional migration or backup of functions (e.g., designation of data
substitutions or alternate data sources can result in some device
inadvertently performing a function not specifically assigned.)
- Identification
of all actions that might be required during the performance of maintenance
functions. (e.g., disable some
protective function, or re-assign a protective function if a certain set of
CTs are taken out of service)
- Status
or availability of all physical devices and ‘logical’ devices
- Clear
indication of which physical device(s) are performing any given function.
Typical
groups of users can be described by some of the typical functions performed:
Systems
Engineering
Design,
construction, configuration, specifications and similar functions.
Protection
engineers and technicians
Verification
of protection functions, modifying protection actions, updating
protection-related devices or functions, designating failover and backup
functions.
Communication
engineers and technicians
Sources
and destinations of data, status of communications-specific equipment, network
status, troubleshooting, designating failover and backup activities.
Substation
operators
Safety
Switching and Tagging.
For example, what devices must be considered to fully disable recloser
functions to a circuit breaker.
In some cases, such devices must also be physically or electronically
‘tagged’ to show the current recloser function status.
The visibility program needs to identify all physical devices and or
communications paths that can cause a reclose to occur.
If electronic tagging is used in any of the devices or path -blocking,
the status of such tagging must be displayed.
The program must be written to support the specific switching and tagging
procedures used by a given utility.
However, the database requirements for such support should be general and
comprehensive.
Simple example
A
very simple example of recloser blocking involving a SCADA system, a Substation
Automation System (SAS) and an IED requires the following functionality:
-
Block
any close commands from the SCADA system, but allow such commands from the
local SAS and the IED.
-
Block
any close commands from the SCADA and SAS systems, but allow such commands
from the IED.
-
Block
any close commands from the SCADA, SAS and IED.
Database
support requirements
-
Data
relationships, sources and destinations, validity, etc.
-
IED
communications facilities, including servers, clients, availability, in or
out of service
-
Physical
IED functionality in terms of the power system
-
Protection
and logic schemes, and where they reside or how they are distributed
-
Perform
consistency and sanity checks
-
Maintenance
of protection system (e.g., settings, operational constraints)
- Topology
of substation power system (bus, connectivity, energization, etc.)
|
WiseOwl™