With the introduction of Intelligent Electronic Devices
(IEDs) the role of the System Integrator has changed dramatically. The
principal cause of this change is the paradigm shift from a system with
unilateral control of slave devices by a single master to one implemented by a
fully distributed architecture that, in addition, provides for peer-to-peer
communications.
To implement this new paradigm, the most important
guideline to the System Integrator is a clear statement from the utility of
their vision for substation automation. The purpose is to
clearly describe how the vision of the utility is used by the System
Integrator to develop a detailed description of six specifications required
for system integration.
It is clear, from the description of specifications that
must be produced, that the System Integrator should be selected at the
beginning of the procurement cycle for the substation automation system. As a
member of the utility’s procurement team, the System Integrator will
contribute language to the procurement specification so as to ensure a
graceful transition to the future system.
Organizationally, the System Integrator must have a
close working relationship with the Engineering and Operational organizations,
but should not administratively report to either organization. This degree of
independence will greatly improve the quality assurance of substation
automation.
The utility must articulate a vision of what they expect
to achieve with their substation automation initiative. As an example, the
vision could be stated as follows:
Substation automation shall be implemented as a
distributed open system to ensure a graceful transition from existing
substation configurations, and to provide a cost effective evolution for
implementing future substation automation technologies. The system will
implement peer-to-peer communications between IEDs so as to guarantee that no
single point of failure will jeopardize the integrity of the protection
scheme. An open communication system between IEDs will require vendors to
implement either approved standards, de facto-standards, or to publish their
application program interface, and thereby ensure interoperability and
interchangeability of IEDs purchased from different manufacturers, and to
provide for third party maintenance of the communication system. Furthermore,
the future substation automation system will provide for a common graphical
user interface for all users, and a common substation configuration schema for
configuring, commissioning and maintaining the substation IEDs.
The utility must insist that all future procurements of
substation IEDs and supporting components meet the requirements set forth in
their vision statement. Furthermore, the utility should retain the System
Integrator in a strong quality assurance role so as to ensure the graceful
evolution of substation automation.
System Integrator responsibilities
Figure
1 shows the products generated by the System Integrator based on four
fundamental inputs required for substation automation. In addition to the
utility’s vision described earlier, the System Integrator must understand the detailed operating
procedures and existing substation configurations. Then, when combined with a
detailed description of the IED capabilities provided by each manufacturer,
the System Integrator can develop the specifications shown in Figure
1.
Target
architecture
The first specification developed by the System
Integrator is the target architecture. This specification will provide a
clear picture of the utility’s future substation automation system and
provide a reference model for developing migration strategies from legacy
systems. The target architecture must identify all substation automation
components and their interrelationship.
In addition to one-line diagrams describing the power
system components, a substation-centric communication network diagram is
needed to describe the communication relationship of all IEDs. The System
Integrator will provide an electronic description of the computerized power
system one-line diagrams and communication network diagrams.
Figure
2
shows an example of the substation distributed communication
architecture. For this example, a firewall is shown between the Utility Wide
Area Network (WAN) and the router to the Substation Ethernet Local Area
Network (LAN). System interfaces to the Utility WAN are described in IEC
61968 and IEC 61970, which use a common interface reference model.
An IRIG-B or GPS timing wire is used to synchronize
the IED clocks so that data from multiple sources can be combined for
post-fault analysis. A high-speed database server connected to the LAN is
used to maintain all substation configuration data, and to record all
substation event data.
Instrument transformers, switchgear and other sensors
are connected to the IEDs by either hardwire or through a process bus as
described in IEC 61850. Some instrument transformers, switchgear and other
sensors have IEDs that provide the capability to communicate over the LAN
which is extended from the control house into the switchyard as described in
IEEE 1525.
A complete description of the functional
and performance requirements for the target architecture is needed to
establish a baseline description of the features required to ensure
interoperability and interchangeability of power system devices and their
IEDs. In addition, the System Integrator will describe all requirements for
reliability, maintainability, etc., and will identify particular
requirements that significantly influence life cycle cost.
Applicable compliance documents
Compliance is best implemented by defining a list of
applicable compliance documents. Then these compliance documents should be
cross-reference in a table that describes the system test and operating
conditions that must comply with one or more specific compliance
requirements. Compliance documents may need clarification to better
understand how to use the document, and how to apply the compliance
requirement. Therefore the System Integrator may, for a specific clause in a
compliance document, add the modifications needed to tailor the compliance
document for a specific substation configuration and operating procedure.
The cross-reference compliance table will provide the
capability to perform a management audit of all substation automation
capabilities that have passed system level testing. IED capabilities that
have passed system level testing with qualifications will be clearly
identified in the cross-reference compliance table, and supporting documents
describing the qualification will be referenced.
System test plans & procedures
The System Integrator for each
substation configuration will prepare system test plans and procedures. The
test plans may be time phased to show a phased build-out of the substation
automation system. The system test procedures should however be specific to
a test sequence and acceptance criteria for a particular substation
automation configuration as described in IEC 61850 and IEEE C37.115.
Acceptance criteria may require
special instrumentation to either measure directly the performance of the
substation automation system, or to collect measurements that will be used
to evaluate the performance and by analysis determine whether or not the
acceptance criteria has been satisfied. The System Integrator will
completely describe the acceptance criteria and evaluation method.
Figure
3
shows the basic reference model that describes the response time
performance requirements. Communication performance needs to be measured in
terms of timing between the sending application and the receiving
application as shown in Figure
3
. The time requirement is the sum of a+b+c, where “a” and “c”
is the time required in each IED communication processor to package and
unpack the information transmitted. The time required to transmit the
message over the communication network is “b”. Accurate time stamping is
required to support this analysis.
Measuring “b” will require a
network communication-monitoring device, which can trap network messages and
time stamp those messages at the interfaces shown in Figure
3
.
A common graphical user interface
(GUI) is needed to effectively implement the vision for substation
automation. Given the high probability that the future substation automation
system will include power system devices and IEDs from different
manufacturers, the computer-aided engineering tools and operating GUIs must
have a common look and feel. A few basic principles should be enforced to
achieve this objective.
Configuration management
Because the utility vision emphasized no single point
of failure, dual substation LANs (not shown in Figure
2
) is used. This requires that new IEDs be dual ported with a hot
switchover capability. IEDs that are not dual ported must be replicated to
ensure reliable and continuous operation.
Figure
1
shows that configuration management procedures, which have been
marked up to include the new substation IEDs are important to the System
Integrator. Figure
2
shows a high-speed database server connected to the LAN. The System
Integrator must define the configuration management specification that
maintains all substation configuration data and manages the records of all
event data.
The database server shown in Figure
2
is implemented using RAID
technology;
therefore the System Integrator must define the backup scheme so as to
provide hot switchover when a failure occurs.
Operational control
Figure
1
shows that operating procedures, which have been marked up to
include the new substation IEDs are vitally important to the System
Integrator to produce a specification for substation integrated
protection, control and data acquisition. Emphasis on “integrated”
is derived from the utility’s vision for substation automation.
Furthermore, based on an integrated concept, the System Integrator must
define the operational control specification that addresses four areas of
communication: access control, settings management, report management and
time synchronization.
Access control
The System Integrator must define a schema for
access control that provides the level of security needed for the utility’s
operating procedure. The System Integrator must define a communication
schema that seamlessly integrates security so as to provide data source
authentication, data integrity, confidentiality and protection against
replay attacks. This schema must be enabled by the communication protocol
selected for substation automation. Specifically, this area of the
operational control specification should address the following:
Settings management
The System Integrator must define the schema for
settings management that provides for positive control and verification of
individual settings as well as group settings. Operationally, settings
maybe input to the IED from a remote terminal, from the local substation
MMI computer or, in some cases, on the front panel of the power system
device.
Because the utility vision emphasized reduced cost,
interoperability and interchangeability of power system components, a
standard browser based on the common GUI should be implemented in all workstations that can communicate to
the substation IEDs. The schema for settings management should be based on the
features of the browser and GUI, and should not require the user to
manipulate settings based on parameter names and addresses used for
communication between IEDs.
Report management
Figure
4
shows a generic Report Reference Model (RRM) that should be used
by the System Integrator to define the schema for report management.
Detailed specifications to implement the RRM may be extracted from IEC
61850 or IEEE 1525. Both standards use an object-oriented framework to
manage reporting.
All IEDs networked on the substation LAN must
implement in their communication processor the functional components shown
in Figure 4
. These functions are used to enable spontaneous reporting
(report-by-exception and cyclic reporting), journal reporting
(sequence-of-events), and report-on-request from the client.
The vertical dashed-line in Figure
4
defines the interface between the Client and the Server. The
System Integrator must provide detailed explanations and operating
procedures to implement the following Server capabilities:
WiseOwl™
