AMPS Communication

The current Analog Model Power System (AMPS) uses equipment which is becoming obsolete. The purpose of our project is to upgrade the protection equipment to more modern, Ethernet based technology, and to document the system to make it a user friendly and modern teaching tool.

Background
The purpose of this project was to upgrade the protection equipment in the Analog Model Power System to more modern relays, using a modern communication system. The old relays were all configured to communicate over various serial protocols, which was cumbersome and difficult to expand. The new equipment all uses Ethernet based protocols for communication. The system is used both as a teaching tool for basic relay operation and as a test bed for various research projects. It was designed to be easily reconfigurable, so that labs can be set up with ease, and to be expandable for additional components to be added for research.

Problem Definition
The goals of this project were to determine the equipment we needed, place it in the rack and wire it, configure the protection settings, and document the final configuration. We were given the functional requirements of each device, and from there we chose our options to fit our system and the constraints of our project. Our communications were all to be done over copper Ethernet cables, using a managed switch. The network could not be directly connected to the internet, but must be accessible remotely, so a gateway must be inserted. For the differential relays, we also added a fiber optic cable directly between them for future students to use if they would like. All of our devices had to comply with the Generic Object Oriented Substation Event (GOOSE) protocol defined by the IEC 61850 standard. All of our controls were to be done using GOOSE messages, with the capability to expand to metering as well with a Real Time Automation Controller (RTAC) in the network.

Project Responsibilities
Our initial division of labor was done by device, giving the SEL-351S and SEL-421 to Fahad, the SEL-2440 and SEL-2730M to Corneliu, the user manual and SEL-411L to Jorge, and the classroom labs, SEL-3530, and SEL-3620 to Garrett. However, after we began work, we quickly realized this was not a practical way to break down the tasks, and we restructured based on what each member was capable of. Corneliu was assigned all of the wiring, labeling, and creating the presentation graphics and poster. Jorge was given the task of configuring all of the relays, to give them the proper settings and trip logic, as well as updating two of our relays which did not comply with IEC 61850. Garrett was assigned all of the auxiliary equipment, including the SEL-2730Ms, SEL-2440s, SEL-3620, and getting the GOOSE messages transmitting between devices. The SEL-3530 was added to the system, but not implemented in any of the protection schemes yet, as this will depend on other projects’ needs.

Design Goals
√ Design and research potential hardware options √ Mount and wire protection equipment from SEL √ Configure communications network √ Design and implement trip logic for 2440 √ Configure basic relay functionality √ Documentation √ Technical presentation at Expo 2014

System Setup
When we were selecting our purchase options, we consulted with Normann Fischer and Brian Johnson on which options were needed. Our system used 5A phase and neutral currents, very few I/O connections, needed GOOSE compatibility, and high voltage power supplies. Using these requirements, most of our equipment choices fell into place after that. Dr. Johnson specified which relays he wanted in the lab, and because SEL wanted us to use exclusively their equipment, we didn’t have too many different options to choose from. To replace the 321 and 311L, we decided to get the SEL-411L, which is a differential protection relay, we chose the better firmware since it costs nothing, and 5 amp phase current. For the networking, we chose four Base-T ports with IEC 61850 compatibility, as well as one fiber port for differential communications. We chose a 4U horizontal rack mount chassis with the most basic I/O package, screw terminal blocks, and the basic power supply which can handle 120 VAC. When selecting options for the SEL-351S, a feeder protection relay, we again chose the best firmware with 5 amp phase current. For the networking, we chose a single Base-T port with IEC 61850 compatibility. We chose the standard interface in the horizontal rack mount, with no additional I/O and a power supply capable of using 120 VAC. For the SEL-421, we used two relays that were already in the lab from previous projects. However, one of them needed a firmware upgrade to use IEC 61850. After getting the firmware upgrade, we changed the part number and then both devices were serviceable. To control the breakers, we decided to use the SEL-2440 Discrete Programmable Automation Controller, because it is capable of IEC 61850 communication and has plenty of I/O ports. Inputs and outputs come in three groups of sixteen, so we chose to use 32 outputs and 16 inputs, rated at 125 V. We got two Base-T ports with IEC 61850 capability, and a standard EIA-232 serial port. For the SEL-3530, the Real Time Automation Controller, we got Base-T connectors with IEC 61850 capability, and no I/O ports in the horizontal rack mount chassis. To connect everything together, we decided to use a managed switch so that we could regulate our traffic to each port. SEL manufactures a managed switch, the 2730M, which met our needs, so we got two of them with all Base-T ports and a low voltage power supply. In order to have our system accessible over the internet, we ordered an SEL-3620 Security Gateway with two Base-T connections in a horizontal panel form factor. This device allows us to remotely configure our relay settings. We ordered our 3355 ruggedized computer to come with Windows 7, an Intel i7 dual core processor, with 4 GB RAM and a 30 GB SSD. We bought a larger hard drive from amazon and copied the old hard drive onto the new one verbatim. For all the wiring, we used the existing rack labels to document how our relays were wired, and used heat shrink to secure labels to the ends of the wire nearest the device. We also created diagrams showing how everything was connected, from the solid copper connections to the Ethernet cables, and the network configuration on every device. When setting up our network, we originally used a VLAN for every bay, and added the necessary ports to that VLAN. Upon talking with Dave Dolezilek, we revised our system to have a separate VLAN for every message, to conform to industry best practices. We assigned IP addresses to every device, and arbitrarily chose a subnet of 192.168.10.0/24 for our network. While commissioning the system, we used the same username and password for all of our devices, making it easy for us to go between devices without having to remember passwords. After this report is turned in, Dr. Johnson will change all the passwords to prevent unauthorized access. For students to use the system, we have added several non-admin accounts to the system, and configured the 3620 to accept multiple user groups so that adding individual users is as quick and painless as possible.

System Architecture
The final installed system is a network of devices, with a port to the outside network through a security gateway. These devices talk to each other often and need high response times, and so the switches are configured to intelligently route all traffic to only the ports needed, to minimize latency and bandwidth. The system is well documented, and explains procedures to modify or expand the setup. By explaining our design choices, the system can continue to be built while sticking to the same standards, preventing it from becoming an incoherent mess that nobody understands completely. This was our goal from the beginning, and a large focus of the project. To test our communications setup, we configured three of the 2440s to mirror the outputs of the primary 2440, using GOOSE messages. We then logged in to the 2440 and pulsed the outputs to ensure that the other devices were receiving the messages. We then set up the 2730Ms, and made sure that the messages were still sending. This helped us iron out some issues with our VLAN configurations. To check our final setup, we used the fault controller to create 30 cycle two phase to ground faults. We then set the relays to all use overcurrent protection, and tested them one at a time to ensure that the relays could trip the breakers properly. After a few tweaks, we finally got all of the relays working and qualified our system.

Future Work
Future work was the main goal of our project. We expect the system to be used by many different labs and research projects. What they choose to do with it depends on their project goals, which we cannot begin to speculate on right now. However, we did not configure many of the metering and status messages that future users may want to read from each device. By setting these messages up in advance, a user can simply plug their device in to a specified port and start reading these messages. This would speed up the process for other users, but would increase network traffic. For future expansions to the network, setting up a redundant network would add value to the protection system. If one network were to fail, the second network picks up the traffic without an interrupt in service. This can be implemented using Parallel Redundancy Protocol (PRP). In addition, by adding a device in parallel with the relays on the PTs and in series on the CTs that is capable of publishing sampled values, relays can be remote from the transformers and still offer the same protection. These would both be useful for future research projects into GOOSE reliability and latency.

Documents

 * 2014_AMPS_TPPPT.pptx
 * 2014_AMPS_ExpoPoster.jpg
 * [[File: 2014_AMPS_Manual.pdf]]
 * [[File: 2014_AMPS_WiringDiagram.pdf]]