Substation Integrated Protection Requires High Availability

by Dennis K. Holstein, Publisher
November 2000

Substation automation that integrates protection over the local area network requires high availability to ensure that when a computer-communication fault occurs, five operations will take place:

	Detection: The fact that a fault exists must be detected by the computer-communication system.
	Diagnosis: If it is not obvious from the method of detection, the computer-communication system must determine which domain contains the faulted component.
	Isolation: If the fault domains are not already electrically and logically isolated from each other, the domain with the fault needs to be isolated from the rest of the computer-communication system so that the fault is contained.
	Recovery: The computer-communication system needs to adjust itself to continue (or quickly restore) operations without the services of the failed fault domain.
	Repair: The failed component -- or perhaps the entire failed fault domain -- needs to be repaired or replaced while the rest of the computer-communication system continues operation. Then the system needs to readjust itself again to the new situation of having the failed fault domain once again able to provide service.

David McKinley, in the October 2000 edition of RTC (Real-time Computing), wrote a very interesting article titled "High-Availability System Platforms." Using David's definitions of fault domains, I expanded the concepts to include communications and adapted the approach to substation automation.

With today's technology , it is simply not practical to build computer-communication system components of sufficient reliability to achieve 99.999% or greater availability. To appreciate why this is the case, consider the hardware and software that makes up a typical computer-communication system. Any hardware component will have some predicted failure rate that can be expressed as a Mean Time Between Failures (MTBF).

Software is also a significant source of potential computer-communication failures, though it does not have a true MTBF that can be estimated in the same manner as hardware failures. If software is "correct," there is no reason for it to fail, ever! However, most complex software systems do contain programming errors. Real-time systems, in particular, are even more prone to having software errors because sequence and predictability are critical. Software errors, will result in external behavior similar to that of hardware MTBF.

This is what you need to do!

Utility engineers must clearly specify in their procurement specification the availability requirements for computer-communication availability.
Vendors, on the other hand, must provide quantitative MTBF data for their components.
The system integrator must then develop a fault domain model to evaluate the availability performance of the computer-communication system.

Where do you want to go now?

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 .