Protection Redundancy Main I and Main II Security and Reliability

Transcription

1 Protection Redundancy Main I and Main II Security and Reliability Roy Moxley, Siemens Abstract - Protection history and practice has long had two relays applied for protection of one line or piece of primary equipment. The traditional approach for these relays may be to use two relays with different or identical schemes or manufacturers. There are issues of human usage and common mode failure that are considered when making a choice of how to best select these two relays. In the case of electromechanical relays it was easy to identify the operating principle and production considerations of a particular relay or scheme. In modern microprocessor relays it is not as clear. There are questions on the best way to balance security and reliability when selecting dual protection of a system component. This paper examines the microprocessor system hardware, software, and firmware aspects of a complete system. Fault tree analysis as well as consideration of human interaction with the relay is included. The many aspects of protection included in a modern protective relay are included; protection elements and algorithms, logic, communications, protocols, as well as production aspects. Guidelines from coordinating councils are considered but specific recommendations are not given in this paper. Information on design and production practices are given to let the engineer applying relays understand the implications of relay selection on the overall security and dependability of the system. Key Words: Redundancy, Security, Reliability Constructing a Protection System When a protection system was constructed of discreet electromechanical relays it was relatively obvious what constituted the complete scheme. Static relays were likewise constructed of individual printed circuit cards, each with a single function. Now we have entered the microprocessor age and relays are commonly assumed to be a discrete scheme enclosed in on box. This distinction, between individual functions and a complete scheme become important as we consider why we apply redundant schemes. Using fault tree analysis [1] consider the diagrams of fig. 1. We can see that the probability of a top event of failure to trip is the multiple of the individual probability of failure to trip of each scheme. Likewise, the probability of a top event of a false trip for redundant schemes is the sum of the probability of a false trip from each of the two schemes.

2 Failure to trip for fault Trip For Non or External Fault Event OR Main I Main II Main I Main II Fig. 1. Fault tree for false trip and failure to trip for two redundant schemes If the probability of a single protection system failing to trip for a fault is 1% (for illustration only) and the probability of a false trip is likewise 1% (again for illustration only) then the probability of a redundant scheme failing to trip is: 0.01 x 0.01 = or 0.01%. [equation 1] The probability of a false trip for a non or external event in a redundant scheme in this case is: = 0.02 or 2%. [equation 2] We are willing to accept the arithmetic increase in the probability of false trip in exchange for the geometric reduction in the probability of a failure to trip. [2] Logical Flaw The problem with the math of the example of figure 1 is that it assumes that the two systems are completely independent. Clearly, if the two systems had exactly the same failure components then the failure to trip top event would be unchanged by putting the two systems in parallel. Of course, if all tripping cases for the two relays were the same then the probability of a false trip would likewise not increase for two systems in parallel. In order to examine the impact of inter-dependencies, let us examine what goes into making a complete protection system for a transmission line. Line Protection System In the case of an electromechanical protection scheme it was fairly straightforward to understand the combination of elements that made up the complete system. Wires could be traced, diodes listed, and trip paths established. We have similar tools in microprocessor relays available although digging to a second (or third or ) level may be necessary. Showing all elements that go into a trip output is one step. Starting with a simple permissive we see logic as shown in fig. 2. Overreaching Zone Permissive received Zone 1 Fig 2. Basic permissive scheme And Or Trip

3 The logic of fig. 2 is only slightly more complex than the basic system logic shown in figure 1. But the complete logic is not shown. Let us expand the view of the elements going into the gate. First the Overreaching (permissive) zone; In order for the distance element of the relay to operate we must have a supervisory overcurrent or underimpedance element operate. Then we have to have no power swing detected, nocvt transient detection and no fuse failure going into the distance element. In the permissive received signal we need to consider if it is received from a contact or a logical signal. If a contact, we have de-bounce timers. If a digital signal we have the digital code, error detection, input mapping, and possibly data encryption as well. This turns the simple diagram of fig. 2 into the somewhat more complex diagram of fig. 3. Timer Permissive received CVT Transient Detection Supervisory Element Out-of-Step Overreaching Zone OR Trip Fuse Failure Zone 1 Fig. 3. Expanded Permissive Scheme Logic. The expansion shown here could proceed to show the logic behind the elements such as CVT transient detection and fuse failure detection. The point is that the complete protection scheme includes much more than the simple distance elements of the main protection. Adding these additional elements to the logic of figure 1 now impacts the results of improved dependability shown in equation 1. Let us examine the impact of this expansion on the math of equations 1 and 2. The expanded scheme of fig. 3 has seven input elements. If the logic behind five of the elements (permissive received logic, CVT Transient Detection, Supervisory Element, Out of Step and Fuse Failure) are common between the two relays and we assume they all have the same probability of failure we would see a significant change. If the two relays of Main I and Main II have every element different then the equations are unchanged. When performing fault tree analysis it is important to remember that the top event outcome may be the inverse of the scheme logic. In this case let s look at a top event of a failure to trip correctly for a fault. Clearly for that to happen we need the failure of any input to an gate or both inputs to an OR gate. This means that the failure of inputs to an gate get OR d together (added) and the failure of inputs to an OR gate get d (multiplied). In order to simplify the analysis, I propose to eliminate the effect of the permissive received signal and timer from the math and assume the zone 1 and overreaching zone have the same characteristic. The result is only an approximation so the impact of the removal is within the bounds of error. Since the supervisory elements of the zone 1 and permissive zone are the same, we will have a top event failure to trip if any supervisory element fails or if both distance elements fail. Using the assumed failure rate given above we then have the result shown in equation 3.

4 CVT Transient Detection failure +Supervisory Element failure + Out-of-Step failure + Fuse Failure Detection failure) +(Distance Element failure) 2 =.01 or 1% [equation 3] Because each of the probabilities can be assumed to be small (or the wrong relay is being used) we can mathematically remove the Distance Element failure term as the square becomes very small. This leaves us with : CVT Transient Detection failure +Supervisory Element failure + Out-of-Step failure + Fuse Failure Detection failure =.01= 1% [equation 4] Or if the probability of failure of each supervisory element is the same, they each equal 0.25%. This exercise in fault tree analysis becomes critically important when we look at two different relays for Main I and Main II. If the relays are completely different then we have the independent equations of the form of equations 1 and 2. Notice that in equation 3 the effect of the main measuring unit (in this case the distance elements) became unimportant in evaluating the overall likelihood of a failure to trip. The only way to challenge this assumption is to argue that the likelihood of failure to operate of a distance element is very large compared to the failure to operate for a supervisory element such as CVT transient detection of fuse failure detection. While official reports, [3] break down operations into setting errors and equipment errors, they rarely go into detail on an operation caused by failure of a supervisory element within a protection system. Equation 4 shows that to do the math of fault tree analysis for a dual scheme it is key to understand what might be common mode between two different relays. The supervisory elements listed here would be included as well as others such as IEC GOOSE message protocol code, serial relay to relay data code, polarizing element code and differential relay communication code. Communication codes especially may be common across different lines or even manufacturers. All these elements that make up a significant part of the protection scheme are part of what is delivered in the relay and should be evaluated in selection of Main I and Main II protection. One of the chief recommendations of the NERC failure report [3] is keeping up on firmware updates in relays, recognizing the importance of firmware in the big scheme of things. If relay schemes applied as Main I and Main II have the same supervisory elements or protection communication code the overall probability of a failure to trip may not be improved significantly by having two separate relays. If the only goal of having two relays is to have one available if the other is out for repair this might be acceptable. Otherwise the selection should be evaluated. Hardware Elements - The second leading cause of relay misoperations (defined as both false trip and failure to trip) in the NERC report, after relay settings and logic errors, is relay failures and malfunctions. These failures and malfunctions include component failures and manufacturing flaws. Let us look at a very simplified version of a microprocessor relay:

5 Terminal Blocks Input Circuits (CV / VT) Digital Inputs A/D Converter/ Filter Processors Output Contacts Communication Ports (I/O) Fig. 4. Block elements of microprocessor relay When considering potential hardware failures that could cross product lines or manufacturers each of these groups needs to be evaluated for both failure mode and impact. While a systematic problem with terminal blocks could cause a higher than expected failure rate it would not have the same possibility of multiple relay failures as a problem with communication code that is active whenever the relay sends data. Likewise of concern is software data buffers that could overflow causing a system problem in multiple relays at the same time, under the same conditions. Manufacturing issues also need to be evaluated for common mode concerns. A problem with circuit boards or input CT s could again cause an increase in failure rate but might not be of as much concern as an active output circuit that could have problems when connected to the same DC system and be called to trip at the same time. Settings and Logic Human factors are not as straightforward to evaluate mathematically as hardware or firmware issues. Setting errors can be reduced by having common setting software across relays used but at the same time errors can be duplicated across relays with the same ease. Conclusions The evaluation of a selection philosophy is a complex issue. Redundant relays for critical applications are required by operating councils but specific requirements are usually left to the individual electric utility. It is important to recognize and evaluate the complete scheme for Dependability and Security so that the steps that are taken to optimize one do not unnecessarily harm the other. If thought is not given to how this is done it is quite possible that an engineer can reduce security without achieving any gain in dependability.

6 References: 1. Answering Substation Automation Questions Through Fault Tree Analysis, Gary Scheer 2. IEEE PSRC, WG I-19 Redundancy Considerations for Protective Relaying Systems 3. NERC Misoperation Report, April 2013, prepared by NERC Planning Committee Roy Moxley Siemens AG 3741 Prune Orchard Rd. Colfax, WA