by John T. Tengdin -- Editor-in-Chief
June
1999
In our first editorial, we described the evolution
of substation LAN performance requirements and the need for performance
testing of substation LAN based IEDs (Intelligent Electric Devices).
There still appears to be
some confusion about the performance requirement stated in the EPRI Report
RP3599 “Requirements Specification for Substation Integrated Protection,
Control, and Data Acquisition”. That document requires the delivery of a
tripping signal – application-to-
application (Italics added) in 4 milliseconds or less. Note that this
is application to application. It is not the time from the start
of a fault to a breaker starting to open.
The processing time in the
protection IED, to sense the fault and make a determination that it is
within (or outside) a trip, zone is vendor specific and is in addition to
the 4 ms. Only when the protection IED changes the state of one or more of
its outputs (trip, block, breaker failure initiate, reclose initiate,
etc.) does the time requirement begin. It is then that the sending IED
would call for the transmission of a multicast message. Likewise, at the
receiving IED end, the time ends when the application changes the state of
one of its logic outputs to reflect the received message. Restating, the
time ends when the message is received at the application, not just the
time in a communications processor.
When multiple simultaneous
messages are sent to the same receiving IED, there will be contentions to
be resolved within the receiving message handling application, which must
be added to the “application to application” time. The 4 ms
requirement does not include the time required to operate an output relay
or SCR. Thus, total tripping time may be significantly longer. The
additional times at the initiating end and at the receiving end are IED
vendor specific. They are obviously of interest to any utility concerned
about total clearing time, but are not a part of the LAN “application to
application” communications requirement.
At the Utility Initiative meeting in Albuquerque in May (following the
PSRC meeting), two relay vendors had information on their preliminary
tests to measure this “application to application” time. In both
cases, the vendors said that they had not yet achieved the 4-millisecond
requirement, but had solutions they felt would reduce their times. Note,
however, that both were testing with a single multicast message, with no
other traffic on the LAN. This
clearly will not be the case when a fault occurs. Every IED that sees the
fault (as either external or internal to its protection zone) will send a
multicast message announcing its change of state. It is the last
message in this burst that must meet the 4 ms requirement. Yet, as one of
the vendors observed, there is no industry agreement as to the number of
messages to be considered, the addressing used, what background traffic
exists, or the configuration of the hubs.
The definition – application to
application – obviously includes all the time on the LAN. On a 10 MB
or 100 MB Ethernet LAN, the time to transport a 256 byte message from an
IED to its hub or from a hub to an IED is not significant (as it is in the
microsecond range). Congestion may occur at a hub if many messages arrive
at the same moment. The hub’s ability to resolve message conflicts was
the topic of study in the COMNET III simulations discussed in our last
editorial. It is also discussed in detail in a Conference Paper[i]
presented at the 1999 PES Winter Meeting in New York. Its title is “LAN
Congestion Scenario and Performance Evaluation”. The authors are Mark
Simon and Charles Sufana – Commonwealth Edison Co. and John Tengdin –
OPUS Publishing.
An Ethernet shared hub receives a message on one
port and transmits it on all other ports. An Ethernet switched hub has
improved performance over a shared hub because it does not have to send
every message out on every port. It checks the destination address in the
message and only sends the message to the port(s) with that address. The
performance difference is dramatic if there are many messages, as shown in
the following table (data from the IEEE paper):
However, in the case of a multicast group
address message, the hub must send the message to all destination
addresses included in the group address. In the limit, if every port is a
part of the same group address message, then the switched hub must act
like a shared hub and send the message to all ports.
Note. In such a case, a switched hub will have no improvement in
performance vs. a shared hub.
It
is unrealistic to assume that only one group address would be used by all
relay IEDs. Such addressing would result in performance shown in the
shared hub column. On the other hand, the simulations reported in the IEEE
paper made the (unstated) assumption that the multicast messages triggered
by the substation event would each have different destination addresses to
minimize collisions at a switched hub. It is also clear that this
assumption is not valid. Each protection zone will no doubt have its own
group address. In addition, redundant IEDs covering the same zone of
protection will most likely use different group addresses to avoid a
common failure mode. The selection of group addresses and their members is
totally dependent on the protection schemes used and hence the IEDs that
must receive a state change multicast message from the initiating IEDs.
Depending on the number of group addresses triggered by a substation
event, and their distribution among switched hubs, the actual LAN
performance will lie somewhere between the two columns.
Let’s examine one
particular situation, the ComEd scenario described in the IEEE paper. The
345 kV lines in that scenario have dual redundant protection schemes plus
three different relay communication schemes. As a result, when a fault
occurs on a 345 kV line, the breaker IEDs for the protected line will each
receive seven multicast messages. These may have different group
addresses, but all will contain each breaker IED’s unique destination
address. In such a situation, a switched hub provides no performance
improvement over a shared hub, as all seven messages are contending for
the same port. As the table shows, the penalty at the level of ten
messages is only ~ 0.6 ms (1.19 – 0.61). However, at the 20-message
level, it grows to over 5.6 ms – and thus will not meet the 4 ms
requirement.
The bottom line is that
the LAN performance will be sensitive to the protection schemes employed.
The IEEE paper shows that multicast messages are very effective in
reducing the number of initiating messages on the LAN. This new analysis
shows that attention must also be paid to the receiving end. The number of
messages to be received by one IED for a given substation event will
clearly affect performance.
In summary, there is a
clear need to establish a test scenario that:
WiseOwl™
