IEC 61850 GOOSE vs. Hardwired Protection Signals:
Which One is Right for Me?
bsmith@enernex.com
865-770-4853
Brian Smith, EnerNex Principal Consultant, has over 20 years of experience, including expertise in substation automation, utility communications, SCADA/EMS systems, and teleprotection applications. As a Certified Information Systems Security Professional (CISSP), he has vast knowledge of communications and protocol technologies.
What if I said the answer may be both? Power system protection is one of the most critical applications within the Transmission and Distribution domains. Just like many other applications utilized in this space, the emergence of the IEC 61850 standards is changing the way utilities approach providing for critical protection functions within an automation system design.
One of the real values of the IEC 61850 standards is that they provide options for utilities to solve design problems. One of those options is the ability to create virtual wiring between two or more devices across an Ethernet network using multi-cast GOOSE messages. But just how far should a utility take things when making the decision to transition from the physical world (hardwired) to the virtual world (IEC 61850 GOOSE) for critical functions such as breaker tripping? It’s an interesting question and a challenging one at that. To start our journey in addressing it, we need to accept two facts about networks:
- No Ethernet network is perfect (and the automation system must be designed with failures in mind)
- Building fault tolerance into your Ethernet network comes at a cost.
Remember that one of the end goals in designing an automation system is to ensure the availability of critical functions. Availability of system components, such as network infrastructure, is just a means to that end. The catch is that, the more the network is relied on for critical protection functions, the higher its availability requirements will be. IEC 61850 and modern networking provide a myriad of options for dealing with network availability including Rapid Spanning Tree Protocol (RSTP), High Availability Seamless Redundancy (HSR), and Parallel Redundancy Protocol (PRP) as options in deploying automation system networks. But as the availability requirements increase for the network, the cost and complexity of the network increases. Many times we lose sight of this fact in designing automation systems and unintentionally overcomplicate things by failing to look at alternative ways to deal with impacts to critical function availability related to network failures.
The simple answer is that it does not necessarily have to be an “all or nothing” approach in that the final automation system design has to either be all network based or all hardwired protection signals. In many cases, a simple network design supplemented by hardwired back-up signals may be more cost-effective and reliable than a complicated network design alone in achieving the required availability for critical protection functions. How does a utility decide what is best for its particular situation? The following process, similar to a Failure Modes and Effects Analysis (FMEA), should be considered when designing an IEC 61850-based protection scheme to zero in on the right answer for your utility.
Figure 1 – Process Overview
Step 1 – Identify Critical System Function – Typically, the critical functions are a subset of the overall functions which the automation system supports. Determining which systems functions are critical will be an individual decision by each utility. One simple method for defining critical functions is to identify anything that, if unavailable, would necessitate the power system asset being protected to be taken out of service (de-energized). Some utilities may include functions which support grid reliability such as high-speed reclosing.
Step 2 – Identify Communication Failure Scenarios – Start with a basic (non-redundant) network design which meets the basic functional needs of your automation system and develop a set of corresponding failure modes. For the purposes of this exercise, focus on the simple N-1 contingencies and not complex failure scenarios (i.e., multiple failures). These scenarios should focus on failures of network components, such as:
- Routers
- Ethernet switches (including those which may be embedded in some end devices)
- Links between routers and Ethernet switches
- Links between Ethernet switches and end devices (including any media converters utilized).
These scenarios should only include end device failures involving the devices network interface card or embedded Ethernet switch. Failure modes in the end devices past that point factor into other aspects of the automation system design not covered in this discussion.
Step 3 – Assess Impacts – What are the impacts to the critical functions identified in Step 1 by each of the communication failure scenarios identified in Step 2? We are going to make the assumption in this step that all devices are still performing as designed (only with some or all of the data which is acquired via the network interrupted during the failure). If one of these scenarios results in a critical protection function being unavailable or not functioning within the design parameters, then take note. After you have gone through all the communication failure scenarios, you then have a list of critical functions that more than likely don’t meet you availability requirements. (Remember, it is the availability/performance of the critical function that we ultimately care about — and we are looking for the best method to achieve that level.)
If the list of impacts is null or deemed acceptable, this indicates that you are converging on a likely candidate for the final system design and you can stop here. If not, proceed to Step 4.
Step 4 – Refine System Design – For the impacted critical functions identified in Step 3, what changes to the system design can be made to improve their availability? Our process assumes that any design changes are physical rather than software (such as relay logic that potentially changes the system behavior). The design change options generally fall into two categories:
- Network modifications — These might include one or more things such as changing topology, adding network hardware, adding additional communications interfaces to the IEDs, or a combination thereof, to minimize the impact of the failure mode.
- Hardwiring — Utilizing hardwired interfaces in lieu of network/GOOSE for one or more critical interfaces.
After the utility has identified the desired design change options, it’s time to select one. Each utility will need to identify the specific factors which will be evaluated to determine the most desirable system design modification, but the main factor influencing system design is cost (both direct and indirect). Direct costs consist of basic capital, operations, and maintenance expenses and are straightforward to calculate. Indirect costs may include more subjective items such as deferred expenses (e.g., increased cost of system expansion resulting from a rigid, lower cost initial system design or increased operational flexibility). Indirect costs are a little more difficult to calculate and it may be more effective to use a basic weighting/scoring system to compare system design options.
Once the potential system modifications have been selected, go back to Step 2 and repeat the process with the revised system design. It’s important to note that any network modifications potentially add new communication failure scenarios. It is OK if you find yourself making more than one iteration through the process before you converge on a solution.
The moral of this story is that this is all about optimizing the system design to support critical operational goals. All system design options need to be considered. Limiting your thinking along a single axis (e.g., network modifications) will increase complexity of the network as the system grows or its availability requirements increase. Utilities may find that a hardwired backup for critical functions is the most cost effective solution, both up front and over the life of the system.
I come from the camp that believes that part of the “art” of engineering something is to find the simplest solution that meets your requirements. If adding hardwired back-up signals for critical functions allows me to implement a much simpler network design while at the same time meeting my availability requirements for the critical system functions, that feels like a win-win to me.
“Simplicity is the ultimate sophistication.” – Leonardo Da Vinci
Want to know more about how EnerNex can support your automation system specification, design, and testing efforts? Feel free to contact me at brian@enernex.com to discuss. EnerNex is uniquely qualified to assist you as our staff has decades of experience in all aspects of utility automation systems from both vendor and utility perspectives.
