You are on page 1of 9

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN

Authors:
Craig Preuss Bob Pellegrini
Black & Veatch Corporation The United Illuminating Company

1. Introduction
Substation integration programs have continued to grow among utilities since the 1990s. Most every utility claims to
have substation integration at some level, but some have just continued to install electromechanical relays and RTUs.
Others have created one or more pilot projects with varying success to prove out new substation technology that is
rapidly changing. Still other utilities have developed multi-year integration programs into second, third, and even
fourth generations, rolling out substation integration to an increasing number of substations.

While much attention has been given to the potential costs, benefits, and architectures of substation integration
technologies, little focus has been given to “how” a business case and new design is developed. This paper will
address the engineering processes and best practices for substation integration. What are the front-end engineering
processes that result in the dramatic transformation of a blank sheet of paper and a good idea into the wiring,
schematics, elevations, point lists, and test procedures that result in a successful project? What are the steps
required? What are the issues and considerations in planning for the implementation? What are the potential risks
and pitfalls? Can they be avoided?

This paper will examine the issues that the United Illuminating Company (UI) faced as they moved from legacy
electromechanical relays to an intelligent substation. This includes detailed consideration of key design decisions in
the substation integration system architecture. What drives protocol selection? How can I plan for data requirements,
security requirements, and functional requirements? This paper will de-mystify how front-end engineering
determines a system architecture that balances rapidly changing technology, NERC cyber security requirements, IEC
standards, and IEEE standards and recommended practices.

2. About UI
UI was formed in 1899 when the Bridgeport Electric
Company merged with the New Haven Electric Company.
UI doesn't generate electricity, but purchases, transmits,
distributes and sells it to residential, commercial and
industrial customers in a service area of about 335 square
miles in Connecticut. As a regional distribution utility, UI
provides electricity and energy-related services to 17 towns
and more than 320,000 customers in the Greater New
Haven and Greater Bridgeport areas. The population of this
area is approximately 726,000 or 21% of Connecticut’s
population. UI owns and operates 26 Bulk Electric
substations within it territory. Additionally, UI owns and
operates both 115KV and 345KV transmission system. UI
is a business unit of UIL Holdings corporation. Figure 1 – UI Service Territory

3. Drawing a Blank
Starting from a blank sheet of paper, how do you draw integration and automation? How is it possible to transform a
traditional substation design with control switches, mimic buses, RTUs, interposing relays, and transducers into an
intelligent substation?

The present draft of the upcoming revision to IEEE standard C37.1 “Standard for SCADA and Automation
Systems”, otherwise known as “The SCADA standard”, loosely defines an iterative process that is used to
accomplish substation integration, or the connecting of IEDs together using one or more communication networks to
distribute RTU functionality and enable automation. This process is not part of IEC 61850 “Communication
networks and systems in substations”. The draft of IEEE C37.1 states that there are multiple, iterative steps:

1. Define near term and long term system functionality (system requirements)

2. Protocol selection (both inside and outside the substation)

3. IED selection

4. Architecture selection

5. Secure the system

6. Define performance requirements

Each step depends on the others, which makes the process iterative. System functionality impacts IED selection,
which can impact the architecture and even make your system vulnerable to cyber attacks. System performance
requirements can impact system architecture, which can impact protocol selection. These are just some examples of
how the process becomes iterative.

These steps may occur in a different order than shown above. IED selection typically occurs first, primarily because
relays and meters exist so that the electrical system is protected and so that electricity is measured. So the paper is
usually not as blank as originally thought: some IEDs have already been selected, some system functionality is most
likely desired – there may be even some ideas on what protocols to use and some general security requirements.

UI was in this situation back in 2005. They were starting their design on the new Trumbull Substation and wanted a
big change: move the substation design from a mix of electromechanical and microprocessor relays with no uniform
backbone communications architecture to an integrated substation that supports automation. However, UI did not
have a blank sheet of paper:

1. UI was already extending their corporate WAN to their substations, so they knew they wanted Ethernet; but
how do you install Ethernet in substations?

2. UI knew the relays they wanted because they had installed and tested several microprocessor relays,
especially at the transmission level, that directly supported Ethernet along with DNP3, Modbus, and IEC
61850; but how do you select a protocol?

3. UI knew that a substation is a harsh environment because they had experimented with substation Ethernet
switches and routers that are compliant to IEEE-1613 “IEEE Standard Environmental and Testing
Requirements for Communications Networking Devices in Electric Power Substations” and IEC 61850; but
what else is required to protect their investment?

These were only a few of the questions that they hoped substation integration would answer.

4. Substation Integration
How do you get experienced personnel who intimately know SCADA masters and IT networks understand
substations with their protection and control schemes, RTUs, transformers, breakers, capacitor banks, and switches,
let alone understand substation integration and automation? What about the other way around? Substation integration
training introduced UI personnel from across the enterprise to the equipment, concepts and issues, reasons, costs,
risks, benefits, and process of substation integration. Inviting everyone is usually not possible, but inviting select
individuals from protection and control, SCADA, IT, operations, metering, maintenance, substation engineering,
planning, technicians, and engineering management is a good start. Once UI completed training, substation
integration began, starting somewhere in the middle of the six step process.

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 2


4.1 Functional Requirements Primary Revenue
A series of conference calls and on-site meetings took Analog Quantity Relay Meter
place to determine the system functional requirements as Voltage ± 0.5 % 0.1%
defined in the draft of IEEE C37.1: Frequency (47-63Hz) ± 0.01 Hz 0.01 Hz
1. I/O Phase Current ± 0.25 % 0.1 %

2. Protection Neutral Current ± 0.25 % 0.4 %


KW, KVAR, kVA (unity PF) ± 1.0 % 0.2 %
3. Ancillary services
KW, KVAR, kVA (± 0.8 PF) ± 1.0 % 0.2 %
4. Time synchronism
Figure 2 – Comparison of Accuracy
5. Programmed logic functions

IEEE C37.1 provides some examples with some typical performance requirements for:

1. Update Periodicity. How often data is updated is not an important issue for UI because Ethernet is being
used in the substation and for SCADA. Polling cycles are not a significant issue on Ethernet networks where
the communication rate is very fast and full duplex.

2. Latency (Seconds). Latency values are not generally published by IED vendors and subsequently were not
used as a criteria for IED selection. The time between when a sensor output is present at the physical
interface of an IED until that value is available from the IED was limited by using a time-stamped value
from the IED. IEC 61850-10 “Communication networks and systems in substations — Part 10:
Conformance testing” requires latency less than 40% of the network transmission time specified in IEC
61850-5 “Communication networks and systems in substations — Part 5: Communication requirements for
functions and device models”. This calculates to IEDs using 1-4 msec for fast processing of digital and
analog I/O.

3. Time skew (Seconds). Time skew values are not generally published by IED vendors and was not used as a
criteria for IED selection. The elapsed time between when the first value in a set of measurements is taken
until the last value of the same set of measurements is taken was somewhat limited by using time-stamped
values from the IEDs.

4. Accuracy (%). IEDs would only be selected if they provided the required accuracy for metering values.
Before metering values were accepted from relays, UI obtained confirmation that the relays were accurate
enough.

5. Resolution (%). The smallest increment of a value that can be resolved, often expressed as percent of full
scale, was limited by selecting DNP3, a protocol that supports higher resolution.

6. Availability (Hours/month). All IEDs are selected to withstand the substation environment … where
possible. This increases the availability of the IEDs when subjected to the various electrical and climatic
stresses in a substation.

While IEEE C37.1 recommends that all these requirements be placed in a tabular form, the approach on the UI
project was concerned more with overcoming other implementation issues rather than meeting performance
requirements. The only IEDs where performance became an issue were the substation computer and monitor,
RTU/data concentrator, networking equipment, and the distributed I/O. The only applicable performance
requirement from above is (6), where IEEE 1613 and IEEE C37.90 were used. Many other implementation issues
were brought out through the use of an “I/O scheme”.

4.1.1 I/O

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 3


I/O is broken down into measurements, status, and control. By defining an “I/O scheme” that uses a block diagram to
show where the data sources are for the substation devices, several issues with each category were discovered and
resolved.

4.1.1.1 Measurements
On the transmission and distribution side, metering from relays was considered accurate enough on the distribution
and on one transmission line. On two of the three transmission lines and both transformers, revenue meters were
already required (on two of three transmission lines and both transformers). The revenue meters are polled for analog
and accumulator quantities. Instead of the number of analog points being limited by the physical space required by
transducers or protocol point count limitations, the actual phase quantities are brought back from the relays and
meters using DNP3. Combinational logic can be used to create a voting scheme that has high reliability that the
actual value is correctly reported. However, metering information is only brought back from the primary relaying or
meters; backup sources were considered to add too much complexity to the system and the primary relays were
considered reliable sources.
VENDOR DESCRIPTION
In addition to these standard metering quantities, some
A 16 status and 4 Form C Outputs, analog
examples of other analog quantities are gathered from the inputs not supported
transformer LTC controller (tap position), battery charger
(battery DC voltage), control house temperature (transducer B Various combinations of digital inputs and
outputs up to 24 inputs and 16 outputs,
wired to distributed I/O), transformer gas monitor analog inputs require separate module
(dissolved hydrogen level), and transformer temperature
C Various combinations of digital inputs and
monitor (winding temperature). outputs up to 34 inputs and 33 outputs,
analog inputs supported

4.1.1.2 Status Figure 4 – Comparison of I/O Combinations for


More than the traditional SCADA status points are Distributed I/O IEDs
required, including selected relay targets, IED status,
communication status, and security status. Dedicated distributed I/O is used to pick up approximately 270 status
points from the transformers, breakers, and control house. Consideration was briefly given to wiring miscellaneous
status points to relays, but this was not implemented because many status points are not associated with relays and
would be lost when the relay was taken out of service for reasons not related to the status inputs.

Several IEDs (primary and backup relays) know the status of breakers. A relay can be out of service for a variety of
reasons while the breaker is still in service or requires operation. Combinational logic can be used to create a voting
scheme that has high reliability of reporting the actual state. However, this results in making the system more
complex and can be avoided by using distributed I/O wired directly to the breaker status contacts. Originally, the
distributed I/O device located in the breaker was used for breaker status, but the breaker status eventually moved
inside the control house because UI wished to have a backup manual control switch there as a backup to the HMI.
Either way, the breaker status is always known by an IED dedicated to breaker status and control points.

4.1.1.3 Control
Control of substation devices was originally
assigned to the primary relays (SCADA)
and backup relays (HMI). Given the desire
to have a manual backup and SCADA
disable in the control house, the difficult
association of some control points with
relays, and the loss of control when a relay
is out of service, dedicated distributed I/O
is used. Distributed I/O devices are very
common in the industrial world, but these
devices create problems with the power
supplies used and ratings required for
substation equipment. In recent years, Figure 3 – Example I/O Scheme for 15 kV Breakers

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 4


several vendors have introduced distributed I/O devices. Each vendor commented that their device was developed as
a result of working with one or more utilities to develop a distributed I/O device. The distributed I/O was required to
directly trip the breaker without the use of interposing relays. This ended up being one of the differentiators between
the available distributed I/O devices. Each of the vendors evaluated had different published contact output ratings.

4.1.2 Protection
Protective functions remain in the relays with traditional hard-wiring of protective control outputs and inputs. One
factor in the system architecture was the anticipated future migration to IEC 61850 that will provide the capability
for high-speed protection using the substation LAN.

4.1.3 Time synchronization


Time synchronization is important because during catastrophic events it is best to have as much synchronized data as
possible to help in data analysis and event correlation. IEDs that can be time synchronized are synchronized using
the most accurate method supported by each IED. Only three methods exist to time synch IEDs:

1. IRIG-B: all relays, meters, and distributed I/O; data concentrator and HMI

2. NTP/SNTP: Ethernet networking equipment (requires an NTP/SNTP server in the substation)

3. DNP: transformer LTC controller, transformer temperature monitor

4. None: transformer gas monitor, battery monitor

IEEE 1588 “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Control Systems” can not be used because no IED vendors (except some Ethernet switches) support that time
synchronization protocol.

Challenges exist in getting IRIG-B out into the substation yard while isolating it so that the copper connection would
not impact system performance. While the distributed I/O device allowed a copper IRIG-B connection, the location
of the distributed I/O out in the substation yard was deemed too risky even though the vendor did provide specific
information on the IRIG-B isolation and also surge protection to IEEE C37.90 “IEEE Standard for Relays and Relay
Systems Associated with Electric Power Apparatus”. Additionally, there was also a concern about the length of the
IRIG-B circuit out into the substation yard. By using the fiber optic port on the distributed I/O devices in the
substation yard, better isolation is achieved than by just using the copper IRIG-B port and the distance is extended.
The fiber optic port allows the IRIG-B signal to be multiplexed on the fiber with serial communications. The same
fiber optic cable used for the LAN connection out to the IEDs in the substation yard is also used for distributing
IRIG-B out in the substation yard.

Selection of the satellite clock required IRIG-B calculations to ensure that the IEDs received the required input
signal. Because of the load from the backup relays and the distributed I/O, the IRIG-B network had to be split up and
required a high-drive output on the satellite clock. The high-drive output requirement made it impossible to include
an NTP/SNTP server on the satellite clock. The substation computer is connected to IRIG-B and is configured as an
NTP/SNTP server that is ± 250 msec relative to the IRIG-B source. All data received in the HMI on the substation
computer is time stamped at the IEDs, or worst case, at the data concentrator to ± 1 msec accuracy.

4.1.4 Programmed Logic


Programmed logic is the basis for substation automation. While the selection criteria for IEDs did not include
programmed logic, most IEDs support their own programmed logic that is based upon their own I/O. In order to
support system-wide programmed logic functionality, a high-speed peer to peer network is required. While IEC
61850 supports this requirement using high-speed messages with guaranteed performance requirements, it is also
possible to use DNP3 over Ethernet for non-protective functions. This can be accomplished by IEDs broadcasting
data to multiple masters or multiple masters polling the same slaves. This type of DNP3 functionality was a
differentiator in the selection of distributed I/O devices and the RTU/data concentrator.

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 5


Another differentiator between the data concentrators was how programmed logic is implemented. While most data
concentrator vendors support an embedded IEC 61131 PLC engine, others only support a text-based or object-based
programming language.

4.1.5 Ancillary Services


Ancillary services are those services left over from the previous discussion: IED configuration, file transfer, log and
data capture, and diagnostic observation. Support for these services requires a high-speed network that supports
more than two connections. Performance can be improved by prioritizing these services, limiting bandwidth usage by
lower priority tasks (given that IEDs generally do not support prioritization).

4.2 IED Selection


As with many utilities, UI knew what vendor they wanted to use for all of the IEDs before system design even began.
Most importantly, they did not want “vaporware”. Reviewing the IED selection took a significant amount of time
because there were many IEDs to review and consider:

1. Primary protection. UI had piloted relays from one vendor that directly supported Ethernet as well as IEC
61850, DNP3, and Modbus.

2. Secondary protection. UI had no interest in connecting secondary relays to the integration system because
they are backup devices. Their original choice was from a different vendor from the primary relays and was
similar in cost and functionality. Since the relays only provided backup functionality and there was a strong
desire to keep the integration simple, less functional and less costly backup relays were selected.
Additionally, UI felt that adding more devices, which provided little additional information value, resulted
in additional unnecessary Cyber Security risk.

3. Breaker monitor. UI had used a breaker monitor in the past that could not be integrated because it did not
support any protocol. Ultimately, the breaker monitor feature in the primary protection relays was used
instead.

4. Transformer temperature monitor. UI had used a transformer monitor in the past that supports DNP3. A
serial device server is required for this IED because it does not support Ethernet.

5. Transformer gas monitor. UI had used a transformer gas monitor in the past that was challenging to
integrate. The original monitor was replaced by the transformer vendor to one that supports DNP3. A serial
device server is required for this device because it does not support Ethernet.

6. RTU. UI was planning on using the same SCADA RTU from the vendor that they always used for
substation RTUs. However, once UI prioritized their system requirements, significant issues were
discovered with the RTU as part of the integrated system. Consequently, an evaluation was undertaken of
competing RTUs and data concentrators from various vendors. A data concentrator was selected based
upon how each IED met the evaluation criteria, but the products were difficult to differentiate. One
surprising difference was one product did not support analog deadbands, one product includes an
interpreted protocol analyzer, and one product
supports IEC 61850. One problem with using a
VENDOR DESCRIPTION
data concentrator is that local I/O is usually not
supported so distributed I/O must be used for 1 10A at 30 Vdc,½A at 125Vdc
status and control. 2 Make: 30 A @ 250 Vdc per IEEE C37.90
Continuous Carry: 6 A @ 70°C; 4 A @ 85°C
Break:24 V 0.75 A;48 V 0.50 A;125 V 0.30 A
7. Distributed I/O. Because a traditional RTU is not
provided and the I/O capability of the relays was 3 Heavy duty protective relay-grade 10A for
direct connection to circuit breaker trip coils
not being used, a distributed I/O device was
required in the design. While ubiquitous in the Figure 5 – Comparison of Distributed I/O Control
industrial environment, distributed I/O devices Output Ratings

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 6


commonly used in the industrial environment require additional design compensations to work in an
industrial environment. Several vendors of relatively new substation-rated distributed I/O devices were
evaluated and one product was selected based upon the flexibility of the product in comparison to the other
products. Additionally, the selected device uses the same contact outputs used by the vendor’s relays to trip
and close breakers. One drawback of the selected product is that a media converter is required for the
Ethernet port.

8. HMI. UI wanted to use their SCADA master HMI in the substation. As discussions proceeded with the
HMI vendor, it was determined that due to technical issues with their product implementation, UI could not
use the SCADA master software at the substation level in the way that they wanted to. UI wanted one HMI
for the substation that was the same at the master as at the substation. UI wanted the tags placed at either
end to be replicated at the other end. These problems, along with others discussed later, opened the door to
evaluating software from several vendors. As the evaluation took place, some criteria became more
important than others. Once the evaluation was complete, all of the evaluated software had many similar
strengths, but software from a well-known and widely-used vendor was selected mainly because it had
fewer “weaknesses” than the other products.

9. Ethernet switches, router, and serial device servers. UI had used Ethernet switches and routers from one
vendor in the past. UI was comfortable with these products and they met the IEEE 1613 requirements on the
power supplies and communication ports.

10. Revenue meters. UI required the use of a particular revenue meter that supports DNP3 and IRIG-B. A
media converter is required for the Ethernet port.

11. Battery chargers. UI had no interest in integrating an intelligent battery charger. However, the charger UI
wanted to use did support DNP3 and Ethernet, so the charger was integrated into the system. A media
converter is required for the Ethernet port.

12. Battery monitor. UI wanted a separate battery monitor system installed. While each one is intelligent and
supports Modbus over Ethernet, the decision was made that there was no need to integrate the device and
that a simple status point would be sufficient.

13. Substation computer. UI knew that they wanted a substation computer that met IEEE 1613. Originally, the
SCADA master software was supposed to run on this computer. However, only one vendor of substation
hardened computers supported the required operating system and none of them supported the required
memory without moving to a different operating system. This is another reason why a different HMI
software package was used as the HMI. In addition, the selected HMI package was known to have been
used by other utilities on the same substation computer. Another useful feature is the substation computer
accepts an IRIG-B input and can act as an NTP/SNTP time server.

4.3 Security
Like many utilities, UI must address NERC CIP requirements. The original plan was to allow remote access to the
substation devices over the SCADA WAN connected to the substation LAN through a router. However, it was felt
that this design would not address all of the NERC requirements and a “defense in depth” strategy was used.

UI monitors physical security at the site by using a variety of physical monitors outside and inside the substation. All
of these physical security systems are monitored.

Other cyber security issues will be addressed by providing network switches and router that include features that,
when implemented, will help UI meet NERC CIP requirements and implement best practices that provide a “defense
in depth”. One area that needed attention from the NERC CIP perspective was the fact that UI had a “routable
protocol” (Ethernet) within the substation. To address this, UI was able to leverage its broadband network to
physically separate the substation network from the corporate network, subsequently reducing the footprint of the
electronic security perimeter.

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 7


In addition, the approach requires an enterprise-based system that was beyond the scope of the substation project.
Remote access requirements are now part of a separate project that will add secure remote access to this system.

4.4 Architecture Selection


The architecture selection was based upon Ethernet because:

1. UI extended their private corporate WAN and SCADA WAN to the substations and they wanted to better
utilize these TCP/IP networks. UI’s existing telecommunication architecture is based upon a private
SONET OC-12 fiber optic backbone. This architecture lends itself to private partitioning of the
telecommunication channels within the SONET payload and therefore satisfied Cyber Security concerns.
For example, both corporate and SCADA Ethernet channels can be partitioned within the backbone and
therefore the channels could be secured both physically as well as logically. The robustness of the SONET
bandwidth was a prime driver in several of the decisions within the substation environment, and especially
utilizing Ethernet within the substation.

2. Several Ethernet-based relays were installed in previous successful pilots and UI wanted to continue using
them due to their ease of use and the support of the TCP/IP protocol suite.

3. They wanted more than just SCADA data out of their investment in IEDs – remote access, operational data
(where SCADA data is a subset of operational data), and non-operational data – and this requires a medium
that can support these requirements with bandwidth and multiple simultaneous connections.

4. There was interest in the system being a design standard that could easily support IEC 61850

Decisions on the Ethernet implementation were happening while IEEE 1615 “Recommended Practice for Network
Communication in Electric Power Substations” was being drafted by the IEEE Substations Committee. All
recommendations from the final draft version of the standard should be implemented on the project (for example, at
the time of this writing, UI had developed an IP addressing scheme which had not yet been reviewed in relationship
to the IEEE 1615 recommendation for private addresses). While some selected IEDs did not support Ethernet, the
decision was made to make the architecture consistent so serial devices were connected to serial device servers. This
worked well because the serial devices were usually located near each other.

Redundancy was not selected because the substation LAN is not initially supporting protection functions and IEEE
1613 compliant switches and routers are used along with fiber optic cables. Issues with redundant LANs include the
increased cost for a LAN that is almost completely isolated inside the control house and segmenting the architecture
because some IEDs do not support redundant LANs.

4.5 Protocol Selection


UI had used DNP3 between their RTUs and SCADA master and there was a strong desire to use DNP3 in the
substation. IEC 61850 was also discussed, but it was decided that using IEC 61850 might be a bit of an
uncomfortable stretch because IEC 61850 requires a true paradigm shift in substation design and engineering. In
addition, the only devices that supported IEC 61850 directly were the relays, data concentrator, and HMI. The one
protocol all selected IEDs support is DNP3. Even if IEC 61850 was selected as the protocol, the integration effort
would not have been significantly reduced and the learning curve would have been steep.

There is interest in moving forward in the future with IEC 61850, which is one reason why Ethernet was selected.

4.6 Performance
System availability was addressed by using substation hardened equipment in all aspects of system design. All
Ethernet equipment meets IEEE 1613, including the substation computer. Any IEDs that did not meet IEEE 1613
(meters, distributed I/O) were connected to a media converter. In addition, fiber optic cables are used to completely

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 8


isolate the system cables from any interference. The only equipment that does not meet IEEE 1613 requirements is
the monitor for the substation computer, which is isolated behind a DC-DC converter designed to meet IEEE
C37.90.

System changeability includes ease of expansion, provision of spare capacity, ease of replacement, and ease of
maintenance. The system architecture is based upon Ethernet and is inherently modular and easily scalable for
expansion. By using distributed I/O, spare capacity is easily provided and can be easily added, although there is a
rather large upper limit in the amount of I/O points the data concentrator can effectively handle. Because of the
modular nature of the system, replacement of portions of the system can be accomplished without removing the
whole system from service. System maintenance covers items such as changing operational parameters as well as the
configuration. With a modular system being supported by multiple vendors, some changes to some IEDs is easier
than others, depending upon the evaluation criteria. Generally speaking, all selected devices support good user
interfaces that are easy to work with in order to affect change in the overall system.

5. Progress
As of February 2007, the conceptual design was finished and detailed design nearing completion. Equipment and
software was being ordered and the vendors for the control house were being evaluated. The next upcoming phases
are the programming and testing phase, where the system components will be programmed and tested in a laboratory
setting. The control house vendor is required to support factory acceptance testing and UI wants to perform the site
acceptance testing. These testing features are in compliance with IEEE C37.1. Additionally, the project received
approval to build an automation test center which will be used for training, testing, and provide a development
environment for all upcoming automation decisions.

6. Conclusions
Making substations intelligent requires the use of integration techniques provided in the upcoming revision to IEEE
C37.1. These techniques are not included as part of IEC 61850 and are still required even if IEC 61850 is being
used. Many IED vendors, except for many relay vendors, do not support IEC 61850 or even Ethernet. Providing a
pathway to IEC 61850 does not require the selection of DNP3, but the use of Ethernet. Selecting IEDs can be a time
consuming process because the “devil is in the details” and careful evaluation is a must in order to prevent last
minute surprises that can derail projects.

7. Biographies
Craig Preuss is the Engineering Manager for Utility Automation at Black & Veatch Corporation. He performs many
different tasks since he works in substation integration and automation. He is a professional engineer in the states of
Illinois and Washington. He earned his bachelor’s degree in electrical engineering from Valparaiso University in
Valparaiso, IN. He earned his master’s degree in power systems from the Illinois Institute of Technology. He has
authored several papers, presentations, and articles on topics dealing with substation integration and automation. He
is a member of the IEEE and is the new working group chair for IEEE C37.1, was involved in the writing of IEEE
1615, and is also involved in other IEEE working groups. He is a member of the ISA (Instrumentation, Systems, and
Automation Society). He is involved in the UCA International Users Group as part of Black & Veatch’s corporate
membership.

Robert Pellegrini is currently the Manager of Protection &Control / SCADA at the United Illuminating Company.
He is responsible for all aspects of Substation, P&C, and SCADA design and implementation. In his 20 years at UI,
he has held several engineering positions as well as managerial positions within the Electric Systems group. He has
also held managerial positions within the Information Technology group at UI. He is a registered professional
engineer in the state of Connecticut. He earned his bachelor’s degree in electrical engineering from Drexel
University in Philadelphia, Pennsylvania. One of his many accomplishments was justifying, designing and building
UI’s private OC-12 SONET telecommunications network. He has also taught Power System Analysis classes at
Bridgeport Engineering Institute in Fairfield Connecticut.

1001010110010100100010011101010010010010001001000100010001000100111110100100010111010001011011111100001010010101011010101010111101

MAKING SUBSTATIONS MORE INTELLIGENT BY DESIGN ▪ 9

You might also like