Substation automation is a catch-all phrase that connotes different objectives and technologies to different companies, and even to different individuals within a company. Perhaps the simplest definition is that substation automation provides a means for obtaining timely information to assist in making operational decisions. Granted, this doesn’t sound like automation. The word would imply that after being “automated” the substation should be able to sort things out by itself. While some of this type of automation does take place, for the most part automation today is really about information. This reality is reinforced by some of the most commonly cited reasons for pursuing substation automation, namely:
- Improved decision making due to better and more timely access to data;
- Faster identification and resolution of faults due to better data access.
Early automation efforts involved installing remote terminal units (RTUs) in substations and making numerous hardwired connections. To monitor relay and switch status, contact points were connected. For metering, analog transducers were put in place. Automation then took a new turn through the introduction of programmable logic controllers (PLCs) to replace the cumbersome collection of auxiliary relays and hardwired logic necessary to accomplish the various inter-locks and transfer schemes found in substations. Finally, real communications were introduced as intelligent RTUs allowed a utility’s SCADA system to communicate directly with the various, and awkwardly named, intelligent electronic devices (IEDs) in a substation.
Current State of the Industry
Two distinct but related developments are driving substation automation today. The first involves the increasingly sophisticated communications technologies being deployed within the substation. The dominant architecture now being used employs some type of communication processor or port switch as a central hub, to which are connected various IEDs. Growing in popularity is the use of a Local Area Network (LAN) in the substation to which all IEDs are connected. This architecture is destined to be the future of substation automation architectures, since it eliminates costly and unnecessary intermediaries in the communications path.
The second development is in the distillation of the various IEDs being employed in a substation. Just a few years ago, typical IEDs in a substation automation project would include: microprocessor-based protective relays; microprocessor-based digital panel meters; PLCs; data multiplexers; RTUs; modems; communication port switches; communication processors specific to a given manufacturer’s relays, etc.; sequence-of-event recorders; transient event recorders; and alarm panels.
This was still quite a bit of equipment to deploy and to get working properly. Combining a variety of functions into one type of device then became the goal of equipment manufacturers. Over time it appears that utilities have voted with their wallets that protective relays are the devices that will become the anchors of the automated substation. The perception that relays are more rugged is one reason. Another reason is that a utility can live without a sequence-of-events recorder or a meter on every feeder, but the relays are a necessity. Subsequently, the market has responded with modern protective relays that can perform not only relaying functions, but often include metering, sequence-of-events recording, transient recording, power quality monitoring, load profiling and custom control logic.
New Technologies
In parallel with these substation automation developments, the seemingly unrelated field of computer science was rapidly maturing the concept of object-oriented programming (OOP). This programming method looks at the characteristics of a data set and treats it as an object. The programming then involves how the objects interact with each other. This eliminates the focus on the detailed construction of the logic inter-relating how individual characteristics interact. For example, it is easier to refer to Jane Doe than it is to refer to a female, age 45, with brown hair, and so forth. If you have ever drawn a box or an arrow in a presentation graphics package, you have interacted with an “object” in the classic OOP sense.
Two developments are introducing OOP to substation automation. The first is in the field of communication protocols. UCA 2.0/MMS is an object-oriented communication protocol developed through the cooperation of a wide cross section of utilities, suppliers and research organizations. By combining the high bandwidth of a LAN with UCA 2.0’s ease of use and its promise of interoperability between various IEDs, UCA 2.0’s advocates promise that utilities soon will be able to access much more data in a much easier fashion than with previous protocols.
Custom Control Logic
Perhaps a more easily understood use of OOP is found in the world of protective relays, which along with communications, form the cornerstones of the modern substation. One of the most useful features of modern microprocessor relays and controls is their ability to execute custom control logic. For many applications, this eliminates the need for separate programmable logic controllers (PLCs) and their associated cost, complexity and wiring. Yet for all of its advantages, contemporary custom logic implementations are still fraught with drawbacks. Most significantly:
- The equation- or command-based structure in use today has a relatively steep learning curve and is non-intuitive to decipher when examining the finished product.
- Equation- and command-based logic is usually entered as a collection of ASCII setting strings. These are prone to human error when transcribed from setting sheets to the actual relay. Indeed, a frequent complaint of relay engineers is that mistakes made in entering custom logic equations is the most common form of setting errors. These errors are notoriously difficult to troubleshoot.
- Most implementations are limited in the number of specific logic elements, such as timers, that may be used. There is no recourse once this number is exceeded.
- Testing the logic requires users to have at their disposal a sample of the relay and a suitable complement of test equipment.
- Preparing documentation as to what, and how, the custom logic works is mandatory to ensure its ability to be supported in the future.
To address these concerns, manufacturers are developing exceptionally powerful, intuitive and easy-to-use software tools that allow utilities to create, implement and test custom logic and control schemes using object-oriented programming techniques.
One such tool, Cooper Power Systems’ IDEA Workbench, provides users with the ability to implement custom logic and algorithms through a drag-and-drop construction technique. Users are able to access any of the relay’s internal signals, contact states, analog quantities and communications inputs. A set of tools is provided to manipulate and combine these signals in a variety of manners. The resulting logic may be used to alter the relay’s operation, operate contacts or initiate communications.
Once constructed, the logic may be tested utilizing the program’s Virtual Test Set feature. The scope of such testing includes not only the created logic, but also its effect on the operation and behavior of the relay as a whole. This eliminates the need to physically test a relay with test equipment. Additionally, the operation of every element of the custom logic is observable while examining captured event records.
One added feature in many of these new software programs is the ability to be downloaded to the relay. The custom logic is never reduced to an ASCII string, but rather is downloaded to the relay as a file separate from the other settings. This ensures that once the logic is developed and configured on the relay, it is essentially out of the way and cannot be affected by routine setting changes. The custom logic is tested and debugged on a PC, and either downloaded to the relay in the lab, or sent to the relay technicians as a separate file that requires no manual data entry process into the relay.
Example
 |
This technique provides for the implementation of exceptionally complex and sophisticated control and adaptive automation techniques. As an example, Figure 1 shows the implementation of some simple logic designed to block the operation of a power transformer’s load tap changer (LTC) for a variety of conditions. The logic drives an output contact that is wired to the LTC. Examination of this figure shows a number of advantages of this new software technology over conventional equation- or command-based logic methods.
- The logic implementation is intuitive. With no further explanation other than Figure 1, the reader is able to determine exactly how the logic operates and under what conditions the LTC’s operation will be inhibited. The logic is implemented in the exact fashion it is typically envisioned in the engineer’s mind.
- Notes were embedded in the logic by the developer to provide helpful explanations or insights to those who may need to examine the logic later.
- The figure shows the logic state during playback of a previously recorded event. The appearance of all elements is dynamic, enabling the user to observe the behavior of the custom logic in operation. Logic gates appear red when their output is logical 1 and appear green when their output is logical 0. Knowing this, it is easy to determine that the LTC blocking contact is closed at this point in time, and the cause is that the reclose logic is not reset (due to being in the midst of a reclose sequence).
- The actual state of all the other driving inputs may be observed by looking at the values displayed inside the green signal arrows.
Conclusion
The sophistication of current substation automation technology is a far cry from that of a few years ago. Advances in substation LANs, advanced communication protocols, and relays that can be re-configured by the user with simple object-oriented programming will dramatically increase the power of automation.
Jack McCall is currently Cooper Power Systems’ Director of Protective Relay and Automated Systems Group located in Franksville, Wis. He has a master’s degree in electric power engineering from Rensselaer Polytechnic Institute and a bachelor’s degree in electrical engineering from Gannon University. He is a member of the IEEE Power Engin-eering Society and has authored numerous papers. More information is available at www.cooperpower.com/idea.
