By Jack McCall
Direct communications between intelligent electronic devices (IEDs) such as relays and recloser controls has emerged as a leading solution as utilities search for opportunities to improve reliability, reduce costs, and provide advanced power solutions for demanding customers. Dubbed peer-to-peer (P2P) communications, the ability of IEDs to share information directly among themselves is a central tenant in industry initiatives such as DV2010 because it offers a number of advantages, including:
- Increased decision-making speed.
- The ability to achieve advanced protection and control schemes that were previously impractical.
- Reduced burden on the SCADA system.
- Lack of dependence upon a centralized SCADA system.
This article details three peer-to-peer communication protocols: DNP 3.0 USRBE, PeerComm, and GOOSE (Generic Object Oriented Substation Equipment) messaging.
A Brief P2P History
Simply defined, peer-to-peer communications allows two or more IEDs to share information over a (usually dedicated) communication channel. The earliest widespread application of such communication occurred decades ago in the transmission-relaying world, where various communication-aided tripping schemes were used to enhance the speed and/or security of line distance protection relays. Users accomplished this by communicating relay status using contact inputs and outputs over powerline carrier or dedicated phone lines.
In the early 1990s, Schweitzer Engineering Laboratories introduced Mirrored Bits, a peer-to-peer communication protocol aimed directly at this application. Mirrored Bits increased functionality by replacing the maze of wires traditionally required to pass multiple status points between contact I/O with a single twisted pair of wires that could pass 16 status points (eight in each direction) between two line protection relays. Mirrored Bits remains popular and many utilities now use this protocol to address a variety of non-transmission line related applications.
In the distribution world, the first commercially successful and somewhat widely deployed peer-to-peer product was IntelliTEAM, introduced by Energyline, now a part of S&C Electric. Unlike the user-configurable Mirrored Bits, IntelliTEAM provided factory pre-configured systems designed to do a specific job. This system uses a custom implementation of one of the currently viable peer-to-peer protocol options, DNP 3.0 in Un-Solicited Report By Exception mode, or USRBE.
DNP 3.0 USRBE
The DNP 3.0 USRBE protocol is an adaptation of DNP 3.0 that was originally intended to reduce the need for continuous SCADA polling and which, coincidentally, allows for peer-to-peer capabilities.
In its standard implementation, DNP 3.0 USRBE–a catchy moniker if there ever was one–works as a peer-to-peer protocol by allowing a DNP device to send a message to another DNP device whenever a triggering threshold is exceeded. Specifically, every data point can generate an “event” message when its value changes by a definable amount. For example, it changes state from a logical 0 to a 1, or the current magnitude increases by 5A, etc. The protocol then saves these events in a buffer until the number of events in this buffer exceeds another definable threshold, at which time all the buffered events are sent. The buffered events will also be sent without exceeding this threshold if too much time passes without the oldest event being sent.
For reconfiguration applications, DNP works very well. For high-speed applications, or applications where a large amount of data must be passed, USRBE becomes somewhat restrictive. First, each message can be addressed to only one other DNP device. So if five devices need the information, five separately addressed messages must be sent. Also, DNP requires each device receiving a message to acknowledge receipt of the message. These characteristics generate considerable traffic on the communication channel, which DNP usually shares with the SCADA system.
Many of the concerns related to communications overhead can be reduced by implementing this protocol over Ethernet. However, most DNP installations are legacy in nature and are either radio- or hardwire-based, so this may not be an easily addressed option. Also, most were not installed with peer-to-peer applications in mind, so rolling out even a reconfiguration application in DNP USRBE may be difficult as many DNP devices do not support USRBE. In addition, the communications network infrastructure deployed in current DNP systems might not support peer-to-peer exchange.
Cooper Power Systems recently introduced PeerComm. Unlike DNP 3.0 USRBE, PeerComm was developed specifically for peer-to-peer applications to address the need to:
- Work equally well over hardwired, radio or Ethernet media.
- Work equally well in substation or overhead applications.
- Offer user-selectable data sets for the type (binary status points, counters, and measurements) and amount of information passed.
- Provide user-selectable network sizes from two to 32 devices.
- Eliminate single point of failure topologies (i.e., no single star configurations required).
- Eliminate the need for additional hardware for networks of more than two devices.
- Implement the logic in distributed fashion.
Each device running PeerComm allocates an array in memory populated with the data from all of the devices on the network (see Figure 1). The devices in a PeerComm network take turns sharing their data by broadcasting it on the network. All of the non-actively broadcasting devices are in listening mode during this broadcast and update their images of the shared data accordingly. Once Device One finishes broadcasting its data, Device Two broadcasts its data, and so forth.
When the common memory array has been populated, the values of any of the array members may be accessed in the relay or control and used to implement custom protection and control schemes.
PeerComm features a continuous communication method, rather than one by exception. CRC 16 data correction validates all data, and data timeouts are monitored. PeerComm also employs a collision avoidance scheme, enabling every device on the network to confirm the validity and timeliness of the shared information. This provides the ability for the protection or control scheme to react differently depending on what information may be missing or unreliable. Because message acknowledgements are not required, the bandwidth demand is much lower than DNP 3.0 USRBE would be for an equivalent amount of data passing.
Unlike networks that concentrate the protection and control algorithms in a single device, allowing that device to direct the actions of the other network members, the algorithms in PeerComm are deployed in each device on the network. This allows each device to operate together as a group, a sub-group, or autonomously depending on the situation and status of data on the network.
PeerComm works equally well with radios for overhead applications, hardwire (e.g., RS-485) for low cost substation implementations, or over Ethernet. The speed of the media used, as well as the size of the network and the amount of data being shared, determines the ultimate throughput of a PeerComm network. For example, passing large amounts of data among many devices over a slow radio-based network may introduce enough time delay to preclude using PeerComm to deploy a high-speed protection application. Yet this same application may be perfectly acceptable if the communication media is moved to Ethernet.
Ethernet and GOOSE Messaging
Ethernet as a media has been mentioned a number of times. Though far from commonplace, installing Ethernet-based LANs in substations is a growing trend. Peer-to-peer protection and control systems implemented over Ethernet address the available bandwidth problem that can occur with other peer-to-peer protocols. For example, DNP 3.0 USRBE becomes much more practical for high-speed applications. Any discussion of Ethernet in substations must include GOOSE messaging, part of the UCA 2.0/IEC 61850 protocol, a peer-to-peer protocol virtually dependent upon Ethernet.
Peer-to-peer communication allows two or more IEDs (such as recloser controls at a substation) to share information.
GOOSE messages are broadcast over the network on an exception basis. An IED will experience an event and then broadcast a predefined message over the network. Other devices on the network are programmed to listen to the entire message, a portion of it, or ignore the message altogether. To ensure the message gets received, the sending device will repeat the message’s broadcast a number of times with exponentially increasing time delays between broadcasts.
Since GOOSE only sends data when needed, it reduces network traffic. However, GOOSE doesn’t provide explicit knowledge of the message’s presence (or absence) to its recipients. The user should also be aware that the UCA 2.0 and IEC implementations of GOOSE are somewhat different, though the IEC implementation appears to be destined as the preferred implementation. PeerComm is interoperable with both the UCA 2.0 and the IEC versions of GOOSE messaging. DNP USRBE is not interoperable with GOOSE messaging.
The use of Ethernet radios to implement GOOSE or DNP over Ethernet is an interesting option. Keep in mind that Ethernet itself is not deterministic in nature, even more so when used over radio. Also consider that Ethernet radios often use public bands, therefore lots of collisions are bound to occur, slowing the response of the peer-to-peer network considerably.
Peer-to-peer networks of relays and controls have the potential to provide extremely fast system reconfiguration, enhanced protection and improved reliability. Typical applications being deployed include high-speed loop schemes, distributed source transfer schemes and bus differential protection. They are undoubtedly an exciting part of our power system’s future.
Jack McCall is the marketing manager for Cooper Power Systems’ Protective Relay Group in South Milwaukee, Wis. Jack has his BSEE from Gannon University in Erie, Pa., and his Masters in Electric Power Engineering from Rensselaer Polytechnic Institute in Troy, N.Y. Jack has worked at Cooper for 18 years.