Automated real-time simulator testing of protection relays

Transcription

1 Automated real-time simulator testing of protection relays by B S Rigby, School of Electrical, Electronic and Computer Engineering, University of KwaZulu-Natal This paper describes the results of a project to develop a proof-of-principle working example of automated hardware-inloop testing of protection schemes on an RTDS Technologiesreal-time simulator. The paper describes the test system configured to demonstrate automated closed-loop testing of the relays in a simple protection scheme, and presents the results of a typical set of such tests. The development of the script file to automate the tests is also discussed. A real-time digital simulator allows actual power system equipment, such as protection relays, to be connected in closed loop with a real-time simulation model for advanced testing [1]. This closed-loop arrangement enables detailed laboratory investigations into the performance of protection schemes to be carried out under highly-realistic conditions. For most types of real-time simulator testing of protection schemes, once the realtime model of the primary plant has been developed and tested, and the protection scheme connected to it, the actual simulation studies are conducted one at a time, with the investigator manually operating the real-time simulator and analysing the response of the scheme to a particular fault contingency. This type of approach is ideal, for example, for investigations where one is interested in recreating, and thereby explaining, the response of the protection relays to a particular contingency that has occurred in the field and to which the actual relays might have responded in an unexpected or undesirable manner. However, in some cases it may be desirable to use a real-time simulator to conduct investigations into the response of a protection scheme to a comprehensive range of fault scenarios, and for each fault scenario to consider different network topologies and system loading conditions. Out of recent collaborations between academia and industry has arisen the question of whether it would be possible to automate hardware-in-loop testing of relays on an RTDS Technologies real-time simulator, so as to run multiple contingency studies on a protection scheme and save the results for later off-line analysis. The RTDS environment does provide a facility for automated repeat testing [2], but in order to make use of this facility the user has to write a script file to carry out the automation in a C-like programming language. This paper describes the results of a project to develop a proof- of-principle working example of such automated testing involving actual hardwarein-loop protection relays. The paper describes the test system configured to demonstrate automated closed-loop testing of relays using the RTDS, and presents the results of a typical set of such tests. The development of the script file to automate the relay tests is also discussed. Study system Fig. 1 shows a single-line diagram of the electrical network model developed on the real-time simulator to serve as the study system for automated relay testing. The system comprises two parallel 400 kv lines fed from sources behind system impedances at each end. Each of the 400 kv transmission paths is split into two line sections and one of these (labeled Line 1 in Fig. 1) is the line section whose protection relays are to be tested using the automated procedure. For the purposes of this study, Line 1 is protected at each of its ends with mho distance relays R1 and R2. These distance relays at each end of Line 1 are set to have a Zone 1 reach of 80% of the line length and a Zone 2 reach of 120% of the line length as shown in Fig. 1, and they are set up in a permissive overreaching scheme, with communication of the permissive signals between the two relays. However, the scheme does not include any weak-end infeed logic settings on the relays. The entire transmission network shown in the diagram of Fig. 1, including the current and voltage transformers feeding each relay, are modelled on the real-time simulator. The distance protection at each end of Line 1 is carried out with SEL 311 C relays [3], each connected in closed-loop with the realtime simulation model, such that the relays respond to the actual real-time variables from the transmission system, and their trip signals are used to open the circuit breakers in the real-time model. In addition, in order to make the system representation as realistic as possible, the permissive transmit/receive communication channels between the two relays are fed via the real-time simulator so that a typical value of propagation delay can be added to each channel (a propagation delay of 8 ms was used during the practical tests). Fig. 1. Single-line diagram of the electrical network used as the study system. The real-time simulation model of the study system in Fig. 1 has been set up to allow short circuit faults to be applied at different locations on both Line 1 and Line 2 in order to test the permissive logic and basic operation of the protection scheme. In addition the study system model has been set up to allow the type of short circuit fault (i.e. A, B or C phase to ground, A phase to B phase etc.) to be varied, as well as to allow variations in the value of the arc resistance of the fault itself. Fig. 2 shows a photograph of the two SEL 311C energize - September Page 28

2 relays, as well as the peripheral hardware and real-time simulator connections required to implement the hardware-in-loop, permissive overreaching distance protection scheme used in this demonstration example. A more in-depth explanation of the hardware-in-loop interfacing methods used for RTDS relay testing can be found in [4]. Manual relay test procedure Fig. 3: Runtime Interface for the real-time simulator model of the study system in Fig. 1. Once a real-time model of a study system such as that shown in Fig. 1 has been configured, and correctly connected to the external relay hardware to be tested, it can be compiled and run on RTDS simulator racks in either manual or automated mode. However, in order to run the real-time model in either of these modes, it is necessary first to develop a Runtime Interface for the model. This Runtime Interface is essentially an interactive software control and monitoring panel that is used to operate, and interact with a real-time simulation, from a standard host computer connected to the RTDS racks. Fig. 3 shows the Runtime Interface for the real-time simulator model of the study system of Fig. 1. For the particular purposes of this study, the Runtime Interface has sliders that can be used to adjust the location of the fault on either Line 1 or Line 2 (measured in percentage of the length of Line 1 from relay R1) as well as a dial to select what type of fault is to be applied at either location. In addition, the Runtime interface has a slider to allow the user to select the value of the fault resistance to be applied. The Runtime Interface also has a pushbutton with which to initiate the fault for the selected combination of fault resistance, type and location. Fig. 2: Photograph of the equipment connections used in hardware-in-loop testing of a permissive overreaching distance protection scheme. Fig. 4: Response of relays R1 and R2 to a 0,001 Ω, single-phase to ground fault In manually-operated mode, the user starts the real-time simulation (also from the Runtime Interface), and selects the type, position and resistance parameters for a desired fault from the Runtime Interface Panel, and then presses the pushbutton on the Runtime Interface Panel to apply the specified fault. Upon depression of this pushbutton, the realtime simulator applies the specified fault and the protection relays operate (or not, as the case may be) in response to this fault. The application of the fault also triggers the Runtime Interface to gather, and graphically display, a range of user specified variables from the realtime simulation model, including a small percentage of pre-fault data for each variable, so that the response of the relays to the fault can be analysed in detail. The real-time simulation is then typically halted, and the user inspects the set of variables recorded on the various graph windows of the Runtime Interface Panel, as well as the front panels of the individual protection relays themselves, in order to assess the response of the protection scheme to that particular energize - September Page 29

3 fault. In this manually-operated mode, the real-time simulation model is manually started and stopped by the user, and for each fault of interest, the parameters of the fault are chosen manually, and the response of the relays to the fault assessed before the next fault of interest is applied. Fig. 4 shows an example of the results obtained from a single, manuallyoperated real-time simulator test on the study system in Fig. 1; in this case the fault considered was a single-phase to ground fault of resistance Ω, located 40% of the length of Line 1 from relay R1. The results in Fig. 4 show how fault information appears to the user at the end of a single, manually-run real-time simulation, as well as how this information is interpreted and analysed. Any switching event in a real-time simulation (such as the application of a fault or the opening of a pole of a circuit breaker) has an associated binary logic variable: transitions in these logic variables can thus be used to determine the exact time at which a fault was applied, as well as the exact time at which a breaker opened in response to a command from an external relay. Fig. 4 shows that the operating time of an individual relay is then determined by subtracting the time at which a fault was applied from the time at which that relay actually tripped. The results shown in Fig. 4 correspond to a low resistance ground fault that is located in Zone 1 of both of the relays R1 and R2 protecting Line 1 in Fig. 1. For this scenario, the results show that both relays do in fact correctly see the fault in their respective Zone 1 and both issue a trip within one and a half cycles as expected. Automated relay testing Once a working real-time simulation case study has been developed, the RTDS environment provides user-support tools that can be used to automate the real-time simulation, data recording and assessment procedures. The automation procedure involves writing a script file in a C-like programming language to replicate (and repeat) both the manual actions performed by the user when running a simulation from the Runtime Interface Panel, as well as the analysis of the data recorded on the Runtime Interface Panel at the end of the simulation by the user. It is relatively simple to automate the manual actions carried out by the user when running a typical real-time simulation: in practice, much of the C code script required to run a single realtime simulation session can be automatically generated by using a macrorecord feature on the simulator to record all the key strokes carried out from the computer during a typical simulation run. The process of automating the post-simulation analysis and interpretation of fault records on the Runtime Interface Panel is more challenging and does require some C programming skill. In addition, the user has to code all the conditional loops needed to iteratively update the parameters to be changed each time the simulation is run during the automated procedure. The RTDS environment does however provide all the necessary script coding language tools to implement automated analysis of fault records. However, it should be noted that a script file can only process and interpret data recorded from within the real-time simulation model itself. Consequently, if any information is required from the external protection relays in order to assess their response to a fault (e.g. whether the Zone 1 element in the physical relays under test actually picked up) this information has to be passed to the realtime simulation model from the relays at each time step during the simulation, so that it is available for processing by the scripting program. A significant number of the interconnections shown in the photograph of Fig. 2 are there specifically to pass internal logic (binary) variables from the relays to the real-time simulator for this purpose. Although the RTDS racks have the capacity to accept as many such binary inputs as are likely to be required, it has been found in practice that the number of such variables that can be passed is limited by the availability of binary outputs on the relays themselves. Fig. 5 shows a flow chart of the script file that has been written in order to automate the testing of the distance protection scheme for the study system of Fig. 1. The flow chart illustrates that at the heart of the script file is the code required to run a single instance of the real-time simulation, and to process and record the data gathered at the end of that instance of the simulation; the three outer conditional loops in the flow chart iteratively update the fault location, fault resistance and fault type so that a different combination of these parameters is used for successive simulation runs. It is possible to add additional such loops to vary other parameters of interest (such as point-onwave of fault inception) but this demonstration case example has been limited to three loops. Fig. 5: Flow chart of the code written to automate the hardware-in-loop tests of relays R1 and R2 shown in Figs. 1 & 2. The specific code that must be written to automatically process and record the data gathered at the end of each instance of a real-time simulation depends on what information the user wishes to obtain from the automated study. Typical examples of information that might be required by the user are: whether each relay tripped; the time for each relay to trip; the mode in which the relays tripped (e.g. which zone elements picked up, whether permissive tripping energize - September Page 30

4 occurred, etc.). As illustrated in Fig. 4, the calculation of the time to operate for each relay is straightforward for a human operator to carry out at the end of a manual simulation run, using simple observations of the relevant binary logic variables recorded during the real-time simulation. By contrast, during an automated real-time simulator test, each visual observation of the recorded data (and subsequent mental deduction) ordinarily made by a human operator has to be carefully coded into the script file: special array processing functions must be used to find each transition in the relevant binary logic variables, sort positivegoing from negative-going transitions, and then determine the time of each such transition before the relays. Operating times can be calculated. However, the C-like scripting language does provide the array processing functions needed to automate the procedure carried out by a human operator when analysing such data records [2]. Fig. 6: Code fragment from the full script file written to automate hardwareinloop relay testing, illustrating the techniques used to calculate the trip time for relay R1. A fragment of the actual scripting code used in this demonstration example is shown in Fig. 6 to illustrate the approach used to calculate the operating time of relay R1 using these special array processing functions. The code in Fig. 6 shows that a function arrayuptransitions is used to search for a one to zero transition in an array Fault: upon completion of each single simulation run, this array Fault contains a complete record of the behaviour of the same binary logic signal that is shown in the first plot window of Fig. 4. The function arrayuptransitions returns an index pointing to the location, within this array Fault, at which any zero-to-one transition was found; the actual value of time during the simulation corresponding to this transition point in the recorded data array is then obtained using a function ixtotime and saved in the variable FltTime. Similarly, the function arraydowntransitions is used to search for a oneto- zero transition in an array Breaker1, which contains a record of the binary logic signal representing the status of the particular circuit breaker under the control of relay R1 during the real-time simulation run: if such a transition is found, it indicates that relay R1 did issue a trip signal, and the index to this transition is again used (by means of function ixtotime) to determine the actual value of time TrTime at which this trip signal was received from the relay. The operating time of the relay Flt2TripTime is then calculated simply by subtracting the value of time recorded in FltTime from that in TrTime; non-receipt of a trip signal from a relay was recorded as a relay energize - September Page 31

5 operating time of 999,99 s in this demonstration example. Similar array processing techniques to those shown in Fig. 6 were used to determine the operating time of relay R2, as well as to determine the final status of the various binary logic variables imported into the real-time simulation model from each external relay at the end of each test. The penultimate stage in each iteration is for the script file to save the results of the automated post-fault analysis described above, in a suitable format, to a single row of an output file (shown as stdout in the flowchart of Fig. 4). The final step in each iteration is then for the script file to execute the necessary commands to reset each of the relays, and close their associated circuit breakers within the real-time model in readiness for the next iteration of the automated testing procedure. Once all the iterations are completed, the output file stdout then contains the tabulated outcomes of each unique test on the protection scheme under study. Table 1 shows a subset of the tabulated results obtained from an automated set of tests run on the study system described in Section II. Each row of the table constitutes a summary of how the protection relays responded to the application of a specific fault and corresponds to a single run of the real-time system model on the simulator. The script file for this demonstration example has been programmed to save the location, type and resistance of the fault applied in each simulation, as well as to record pertinent information from each relay at the end of each simulation run (e.g. whether the Zone 1 or Zone 2 elements picked up, which phases the relay determined to be in fault, permissive communications etc.). Finally, the script file has been programmed to calculate and record the time to trip for each relay (in cases where the relay does not trip, the recorded trip time of 999,99 s allows for easy visual identification during later off-line analysis. The full table of results (not shown here due to space restrictions) documented the parameters and outcomes of 180 separate individual real-time simulator studies of the example protection scheme, run in automated mode by the script file, and requiring no user input other than to start the procedure. Once started, the script file runs unattended (including automatically resetting the protection relays at the beginning of a simulation run) and, upon completion, provides a flat text file containing a row-oriented, comma-delimited table of data such as that shown in Table 1; the only subsequent manipulation that may be required by the user is simply to load this data into a spreadsheet programme, although the data can easily be read and analysed as a flat text file if desired. It needs to be borne in mind that each of the two different modes of real-time simulation (manual and automated) has advantages and disadvantages and, ideally, they should both be used to complement one another. Automated mode allows a large number of simulations to be run at a time, to cover a wide set of scenarios, but provides limited information on what happened during each simulation run. By contrast, running a single simulation in manual mode is more cumbersome, but a full set of variables is available at the end of the simulation run to show how both the transmission system and protection relays behaved before, during and after application of the fault. Once an automated multi-run simulation study has been completed, it is possible (and advisable) to analyse the output data row by row, and repeat specific cases of interest in manual, single-simulation-run mode (for example to carry out more detailed analysis of fault scenarios of particular interest, or of cases where the relay may have operated in an unexpected manner). A selected set of individual case results from the automated study of Table 1 is presented to illustrate this point. Fig. 4 has already shown the results of a single, manuallyoperated real-time simulator run of the study system for a 0,001 Ω, singlephase to ground fault located 40% of the length of Line 1 from relay R1; this scenario corresponds to one row of data saved during the automated test run, shown as row 1 in Table 1. As discussed earlier, the particular test considered in Fig. 4 corresponds to a low resistance ground fault that is located in Zone 1 of both relays R1 and R2 of the protected Line 1 in Fig. 1. Row 1 of Table 1 summarises how the automation procedure has extracted information, both from the realtime simulation variables in Fig. 4 and from binary variables passed to the simulator from the two relays. The results in row 1 show that each relay detected a phase A to ground fault in its respective Zone 1, and tripped in approximately 1½ cycles (30 ms for a 50 Hz system). Fig. 7 shows the results of a single, manually-operated real-time simulator run of the study system for a 34 Ω, singlephase to ground fault located 40% of the length of Line 1 from relay R1; this scenario corresponds to the second row of data in Table 1, as saved during the automated test run. The fault considered in this case is located in the same position as that considered in Fig. 4 (in Zone 1 of both relays), but as a result of the high fault resistance, relay R2 actually sees the fault in its Zone 2. However, relay R2 receives a permissive signal from relay R1 and therefore trips permissively allowing fast clearing of the fault at both ends of the line. Fig. 8 shows the results for a 40 Ω, single-phase to ground fault, once again located 40% of the length of Line 1 from relay R1; this scenario corresponds to the third row of data in Table 1, as saved during Row Dist FltName FltRes Trp_R1 Z1_R1 Z2_R1 A_R1 B_R1 G_R1 PTr_R1 TrpTime_R AG 0, , AG , AG , AG ,99 Row Dist FltName FltRes Trp_R2 Z1_R2 Z2_R2 A_R2 B_R2 G_R2 PTr_R2 TrpTime_R AG 0, , AG , AG , AG ,99 Table 1. Subset of the tabulated results obtained from the automated hardware-in-loop relay tests. energize - September Page 32

6 specific manner, in particular for cases where understanding the response of the protection scheme requires detailed consideration of inter-relay communications, together with a careful examination of the time-sequence of these communications. Fig. 7: Response of relays R1 and R2 to a 34 Ω, single-phase to ground fault the automated test run. The fault considered in this case is located in the same position as that considered in Figs. 4 and 7 (in Zone 1 of both relays), but now the fault resistance is sufficiently high that it is actually seen in Zone 2 by relay R1, whereas relay R2 initially does not see the fault in either its Zone 1 or Zone 2. Relay R1 therefore trips only after its Zone 2 timer has timed out (no permissive signal is received from relay R2 until after R1 has tripped). Once relay R1 has tripped, relay R2 is then able to see the fault in its Zone 2 and, because it has already received a permissive signal from relay R1, it then trips within one and a half cycles of the relay R1 trip. (Recall that no weak-end infeed logic is included in the protection scheme). The particular response of the protection scheme in this study example to the fault scenario considered in Fig. 8 is a useful illustration of the complementary strengths of the two approaches to relay testing using a real-time simulator. The automated testing approach allows the user to work through numerous fault scenarios very quickly (once the scripting code has been developed and tested) to identify potential cases of interest. By contrast, manual operation of the simulator for a single fault scenario is a much more efficient method of determining why a protection scheme responded in a For example, for the scenario considered in Fig. 8, the results from the automated test (row 3 in Table 1) indicate that each relay saw the fault in its Zone 2, and furthermore that each relay received a permissive signal from the relay at the other end of the line, which, at first face, would suggest that both relays should have tripped permissively and in approximately two ac cycles. However, what the results in row 3 of Table 1 do not show is that for this particular high resistance fault, because of weak-end infeed conditions, relay R2 does not see the fault in its Zone 2 until after the relay at the other end has tripped. This insight requires not just knowledge of whether the Zone 2 element of relay R2 picked up, but also when this element picked up relative to the time at which relay R1 issued a trip signal. While it is possible, in principle, to include such information and analysis in the tabulated output of the automated tests, this would require the development of a significant amount of carefully-designed code within the script file used for the automation procedure. It needs to be borne in mind that the development of the script file for automating the relay tests itself requires time to design Fig. 9 shows the results for a 55 Ω, single-phase to ground fault, once again located 40% of the length of Line 1 from relay R1; this scenario corresponds to the fourth row of data in Table 1, as saved during the automated test run. The fault is once again located in the same position as that considered in the earlier figures (in Zone 1 of both relays), but now the fault resistance is sufficiently high that it is actually seen outside of Zone 2 by both relays. Consequently, neither relay operates despite the fact that the fault is in fact on the protected section of line. energize - September Page 33

7 and test, so there will inevitably be a trade-off between the development time of the automation script, and the time required to conduct a small number of detailed tests by hand after the results of an automated study. Conclusion This paper has presented the results of a project to develop a proof-of-principle working example of automated hardware-inloop testing of protection schemes on a real-time digital simulator. The paper has described a simple example study system used to demonstrate automated testing of a protection scheme, and presented the results of a typical set of tests. In particular, the paper has contrasted the different levels of detail obtained from the results of manually operated, single-run real-time simulator studies against those obtained from automated, multiple-run simulator studies. It has been argued that the automated approach to testing protection schemes on a real-time simulator is best suited to quickly identifying fault scenarios of interest, whereas the manual approach to testing is a more efficient method of determining the reason for the particular response of a scheme to such scenarios. A thorough regimen for testing protection schemes using a real-time simulator should therefore use a combination of the automated and manual testing approaches. Fig. 8: Response of relays R1 and R2 to a 40 Ω, single-phase to ground fault Fig. 9: Response of relays R1 and R2 to a 55 Ω, single-phase to ground fault Acknowledgments The author acknowledges the support of the University of KwaZulu-Natal, the Durban University of Technology, the Eskom TESP programme and the Department of Trade & Industry THRIP programme. This paper was presented at the IEEE PowerAfrica 2007 conference at Wits University, Johannesburg, in August 2007, and is published with permission. References [1] McLaren P G, Kuffel R, Wierckx R, Giesbrecht J, Arendt L,.A Real Time Digital Simulator For Testing Relays., IEEE Transactions on Power Delivery, Vol. 7, No. 1, Jan 1992, pp [2] RSCAD Runtime Manual, RTDS Technologies, Winnipeg, Manitoba, Canada. [3] SEL 311C Protection and Automation System Instruction Manual, Schweitzer Engineering Laboratories, USA. [4] Rigby B S:.Closed-Loop Testing of an Overcurrent Relay Using a Real- Time Digital Simulator., Proceedings of the IEEE Africon 2004 Conference, Gaborone, Botswana, September 2004, pp v. energize - September Page 34