By Nathan Bingham, POWER Engineers Inc.
Substation automation can mean different things to different electric utilities. To one, it could mean adding a supervisory control and data acquisition (SCADA) system for remote monitoring and control to a traditional substation with mimic panels and an annunciator. Another utility may replace the mimic panel and annunciator with a station human machine interface (HMI). A third utility might use substation automation to replace all interlocks, cutouts and other controls so that all station control is performed and monitored using a combination of microprocessor-based relays, substation controllers and HMIs. Finally, a utility could take a more literal interpretation of the term and define it as actual station automation, including such items as automatic voltage control, power fail actions, intelligent load transferring between stations, load tap changer control and other automated routines.
Whatever your definition of substation automation, it is important that a well thought-out design process is used to ensure that once the system is in place it meets all or as many of your needs as possible.
Several different approaches can be taken when defining a system’s requirements. In some cases, a consultant is hired to assess the existing or non-existent system and create a specification. Other times, the utility’s internal engineering group creates a specification based on their understanding of the needs. Another option is when a committee is formed to identify needs and a specification developed around their findings. Whatever approach is used, the key is to represent all interested parties adequately. When all interested parties are adequately represented, determining that a system will meet every party’s needs naturally happens in the design phase, not during commissioning.
Defining the Requirements
The purpose of the aforementioned committee should be to define and prioritize the needs and wants for the system rather than designing a specific system. Once identified, it is relatively easy to create a system that will meet those needs. The task of staying within budget may be slightly more difficult, but can be done by prioritizing needs and removing those with a lower priority. Selecting equipment with future expansion capability provides the option of adding this functionality when the budget permits.
Selecting the Architecture
With the requirements well-defined, the next step is to select an architecture. Deciding which is better between company A’s “Intelligent SCADA TCP Network Communication” (ISTNC) system or company B’s “Dynamic User Managed LAN” (DUMLAN) system, or one of the many actual acronymed systems that exist can be overwhelming. The important thing is to select the architecture that best fits the defined needs for the system, while avoiding the trap of selecting equipment based on the best sales presentation.
When designing an automation system, there are two basic types of SCADA system topologies: centralized or distributed-the main difference between the two being where the equipment is mounted. Is it all mounted in one cabinet with all of the wiring run into that cabinet, or is the equipment for monitoring a station device located near the device so that wiring requirements are minimized? Most systems use a combination of the two with the equipment distributed within the control room rather than out in the station yard. A typical exception is the transformer control and monitoring equipment, which is usually mounted at the transformer.
Once the type of topology is selected several more choices present themselves. Will a station LAN be used or serial communications? Should intelligent electronic devices (IEDs) or I/O modules be used? If IEDs are used, do they need remote access for maintenance and diagnostics? Will there be a high-speed communications connection into the station? If you select equipment based on the answers to these and other questions, you may end up with a well-designed and integrated system. Unfortunately, it may not meet some of the functional needs of the station or, at a minimum, upset your relaying department by straying from their protection standards.
For this reason, it is typically better to choose the IEDs first and then design the SCADA system that best integrates with the IEDs; thus, meeting as many of the previously identified needs as possible.
The Integration Task
In the not-too-distant future, the integration task will be much easier because all IEDs will have Ethernet communications onboard. All that will be needed is an inexpensive substation gateway device consisting of a substation-hardened Ethernet switch with a firewall, web server and data concentrator. In this ideal scenario, the gateway devices would provide secure access to all IEDs for maintenance, while collecting data from the devices to display on a local web server HMI and provide a subset of the available information to the energy management system (EMS) monitoring the station. There are substation gateways currently available that do some or all of that, but the Ethernet-enabled IEDs are relatively expensive and not available from many manufacturers. Most utilities have only a few of them, making the integration task more difficult.
There are several things to consider when selecting whether to use Ethernet or serial communications. Ethernet provides higher data throughput, supports multiple data and diagnostic channels over one connection, and can be used for protective relay communications. On the other hand, Ethernet requires more training for the maintenance staff, and the substation network equipment is more expensive. Serial communications offer simpler configuration and maintenance, less expensive equipment, and work with all IEDs. However, with serial communications, multiple connections are often needed to an IED for data and maintenance communications, speeds can be slow, and multiple data concentrators may be required, which adds complexity. Since most IEDs presently don’t support Ethernet, even if you choose that topology you will probably end up with some serial communications mixed in as well.
Selecting the Data Concentrator
The next step for most systems is selecting a data concentrator. While it is true that some systems don’t use a data concentrator, they do play an important role due to their capability to buffer events and reduce the amount of data sent to the HMI. This capability is becoming even more important as some IEDs can have data maps with thousands of data points.
The three common types of concentrators include: communication processors, remote terminal units (RTUs) and programmable logic controllers (PLCs). As their name suggests, communication processors are strong in communication capabilities. They typically have eight to 16 serial data ports, Ethernet capabilities and minimal I/O capabilities. For the most part, RTUs have significantly advanced from what they were years ago, so, today, their communication capabilities approach that of communication processors. What sets an RTU apart is that they also offer physical connections to a large amount of I/O. PLCs also have evolved, though communications typically remain an add-on to their main function of collecting and processing I/O, which is where they excel.
Embedded PLC-type logic is available on any of these platforms, making the three devices very comparable in this area. Therefore, device selection involves more than just a comparison of the features, it is also an evaluation of the ease of configuration and upgradeability. If you commonly use PLCs for other functions in your utility, using one in a substation may be a good selection, as you will have personnel who are familiar with the equipment. For others, an RTU with a simple web-based interface may be the best choice as they are generally easier to configure and modify. Other things to consider include: Is there I/O that won’t be collected by IEDs? Does the station have a high-speed communications link? How much remote IED access is needed? Will there be a large enough installed base of equipment to keep staff trained and current on the equipment? Does the data concentrator need to interface with legacy equipment? And does the device meet the needs identified in the planning stage?
What to Do with the Information
While the amount of data available from a substation automation system has steadily increased, the amount of information that a system operator wants to see has not. Those who are in need of “non-operational” information are the system planners, protection engineers and maintenance personnel. Traditionally, the only connection to the substation was for SCADA/EMS information; a second connection was required to obtain the non-operational data. In some cases, a dial-up connection has been available for this non-operational information, but it is not very practical as data downloads are slow and time consuming. If the EMS communication system has the capacity to scan the non-operational information, one option is to scan and write it to a database that is not associated with operator screens.
Another option is to replace existing communication links to the substation with a higher-speed digital connection, such as frame relay or DSL. This non-operational information can be made available by running two data channels over one connection. This does not need to be a high-speed connection, 56K connections are usually more than adequate. Once this connection is in place, the non-operational information can be retrieved easily and stored in a database by an application other than the EMS. In either case, once the data is entered into a database, an interface will need to be created so the non-operational users can access it. Some utilities will do this by displaying secured web pages over the company intranet or by providing users with software and shortcuts to easily extract data from the database for viewing.
No mater how this data is presented to users, it is important that this final task is not left undone, because until this information is easily accessible your company will not realize the full value of a substation automation system. The value realized comes from using this information to improve system planning, reduce maintenance costs and track/troubleshoot system disturbances.
There is no right or wrong answer in the design of a substation automation system. The key to success involves carefully listening to the requirements of all involved parties and seriously considering technical alternatives to design a system that meets everyone’s needs. By following a good design process, a utility will not only end up with a quality substation automation system, but will be able to better achieve their main goal of providing uninterrupted service to customers while reducing operating expenses.
Nathan Bingham focuses on energy automation for POWER Engineers, a 600-person consulting engineering firm specializing in energy, facilities and communications. Throughout his career, he has pursued automation challenges with a particular emphasis in the design and implementation of substation SCADA and distribution automation systems. He is instrumental in providing energy clients with innovative solutions.