Performance Testing
Home Up About OPUS Search Take a Tutorial News Services Registration Subscribers Calendar of Events Newsletter Hot Links

WiseOwl
                                       
The Secure Automation Developer's Resource

 

 

We need LAN performance testing

by John T. Tengdin -- Editor-in-Chief
April 1999

Many of us have the vision, so far unrealized, of one high performance LAN in a substation for both protection and control. Just a few years ago, it was common for protection to be the sole domain of electromechanical or solid state analog relays. There were no communications ports. Remote control, if it existed, was via hard wired connections to a SCADA RTU. Local control was all hard wired. Then along came the first microprocessor based protective relays. Continuing past practices, they were primarily for protection, with limited control capability.

Five years ago, there was serious discussion of substation architecture with two separate LANs – one for protection and the second for monitoring and control. It was felt that if the functions were split between the two LANs, then the performance requirements for the relay LAN could more easily be met. The concern was the effect of large file transfers and SCADA updates on the relay performance.

Work had begun on EPRI Project RP3599 Requirements Specification for Substation Integrated Protection, Control and Data Acquisition. During the course of developing that specification, the IEEE Power System Relaying Committee (PSRC) did an extensive review. Out of those discussions came an agreement that protective relay tripping over a LAN required the delivery of a tripping signal – application to application – in 4 milliseconds or less. That requirement has been stable since December 1996.

The 4 ms performance requirement is most critical during a major substation event, so a number of studies were undertaken to 1) define the level of background traffic to be used, and 2) measure message delivery times with that background traffic load. These studies showed that the background traffic over a wide range (up to 5 X a very heavy load) without having a measurable effect on message delivery times. However, there was a major effect based on the number of messages. Stating this another way, creating a separate LAN for control and monitoring would have no effect on relay performance. And since current design microprocessor relays have extensive monitoring and control capability, a separate control LAN would mean two ports into each relay.

So what is a likely maximum number of protection messages to be generated by a major substation event? Commonwealth Edison relay engineers looked into this question. Starting with a typical 345 – 138 kV substation, they assumed that a tornado had hit a tower carrying 2 – 345 kV and 2 – 138 kV lines, creating faults on all four lines. With redundant protection and wired connections, they found that the event would trigger 144 discrete relay outputs. Analysis showed that, in a messaging system, some of these outputs could be combined in one message, and that some of the messages could be multicast. With these combinations, the number of required messages was reduced to 38, all arriving on the LAN at essentially the same time and to be delivered in < 4 ms.

Under EPRI sponsorship, SRS Technologies ran simulation studies to determine the performance of 10 MB and 100 MB shared and switched hub Ethernet LANs. They studied the effect of simultaneity on the delivery times. That is, what is the effect if all the messages arrive within one microsecond, 10 µs, 100 µs, or within 1 ms. They also varied the number of messages from 10 to 100 to determine worst case performance.

These simulations showed that a 10 MB shared hub LAN can deliver ~ 15 messages in < 4 ms. They also showed that the 10 MB switched hub, and both the 100 MB shared and switched hub Ethernet LANs could deliver at least 100 messages within 4 ms. The details of these simulation studies were presented by your editor at the IEEE Power Engineering Society 1999 Winter Meeting in New York. The Conference paper was titled "LAN Congestion Scenario and Performance Evaluation".

Thus the potential is clearly indicated by this simulation study that an Ethernet LAN can support very heavy message traffic. We also recognize that it will be some time before substation LANs are used for primary protective relay tripping duty. The PSRC Working Group H5 is underway on a new IEEE standard PC37.115. It has a very long title "Standard Test Method for Use in the Evaluation of Message Communications between Intelligent Electronic Devices in an Integrated Substation Protection, Control, and Data Acquisition System". Given the time it takes to develop and gain approval of a new IEEE standard, it will be late in the year 2000 before the document reached the balloting stage.

But the industry can’t wait. Many projects are in the wings, with utilities unwilling to commit based solely on simulation studies. What is needed now is true performance testing.

In the meantime, under the umbrella of the Utility Initiative, a number of substation LAN projects, using the UCA 2™ protocol, are planned for substation installation or laboratory testing in 1999. There has already been some limited interoperability testing, to prove that an operator at an HMI can read data out of a relay. There has been only limited testing of the multicast method, developed in the initiative, and needed to reduce LAN traffic.

Simulations are not enough. The testing by one manufacturer of communications between his products is not enough. Relay engineers want to see the results of actual timed tests, from the start of an event (fault) to the energizing of a trip coil, and with a combination of several IED manufacturers’ products. Without such tests, there will be limited industry support for a single substation LAN.

Yet none of the EPRI sponsored Utility Initiative projects have such an important test planned. If UCA 2™ is to be useful and meet its full potential in the substations, it’s time for the EPRI members to speak up. Let your voices be heard. Make sure the tests being planned meet your needs. If necessary, run your own actual timing tests. Simulations are not enough.

Where do you want to go now?

Back Up Next

 
Send mail to postmaster@opusss.com with questions or comments about this web site.
OPUS Publishing and OPUS Subscription Service are trademarks of OPUS Publishing. All other products mentioned are registered trademarks or trademarks of their respective companies.
Copyright © 2001 OPUS Publishing. All rights reserved.
Last modified: Sunday August 01, 2004 .