The most frequent causes of protection misoperations are setting, logic and design errors, caused for the most part by the increasing complexity of modern protection systems. Line differential protection is a case in point. To date, dedicated test plans and sequences have been created for every test set and every test case, all of which had to be calculated and evaluated individually. By combining the three core functions of the test process in a software package, OMICRON electronics is raising the security and dependability of system test results to a new level.
When commissioning a protection system, utilities always endeavour to test relays in a way that reflects how they will later be used in operation. Line differential protection fulfils its function using two or more relays that communicate with each other. The relays are distributed across various substations. The testing of line differential protection under operational conditions, or as realistically as possible, requires the extremely precise time-synchronised simulation of a fault scenario at each end of the protected line, also referred to as an end-to-end test.
To date, a separate test sequence was created for each end of the line. In the facility, a phone call is made to a colleague at the opposite end so that the respective pair of test cases can be started at exactly the same instant. This methodology has stood the test of time. However, what is evident is that the costs involved and the susceptibility to errors of this approach – in its preparation, execution and troubleshooting – are very high. This has led to the scope of the test being kept to a minimum and even avoiding end-to-end testing altogether, relying instead on the self-tests carried out by the relays. But it is precisely the end-to-end test that guarantees that the protection is working securely, dependably and selectively. An innovative solution has, therefore, been developed that enables this important test to be carried out at a reasonable cost while still satisfying the testing prerequisites.
The end-to-end test as a system test
The main purpose of an end-to-end test is to validate the communications connection. However, it can also be used as a system test.
Studies such as the NERC Study have shown that most protection misoperations are caused by incorrect settings, or logic, or design errors. This is due to the complexity of the power systems and the increasing demands, resulting in an ever-growing number of protection and logic functions, not to mention relays. A system test can be a great help in detecting the faults that can occur as a result. If a threshold has already been calculated incorrectly in the design, a conventional test is only able to check if the relay picks up at the incorrect threshold. This fault can be detected by simulating the power system while calculating the end-to-end test. If we calculate the test signals by simulating a fault at 70 per cent of the line, it is possible to validate whether the settings would in fact trip a fault at 70 per cent instantaneously.
Logic errors occur most frequently when coordinating the individual components, for example, different interval times in the event of an autoreclosure (AR) at each end. Such an error is easy to identify with an end-to-end test. Coordination is not only required for differential protection. As a backup, a relay often has an additional distance protection function with a communication scheme; additionally, in transmission systems, a separate backup protection relay is fitted. Practical experience shows that faults also occur in the coordination between the primary and backup protection systems. These are not detected unless a system-based testing approach is adopted, as seen in the example of the Irish utility ESB. In this instance, the AR of the backup protection was blocked by the primary protection, resulting in unwanted three-pole tripping. The cause was a single incorrect setting in the backup protection relay. This demonstrates that the system test has to cover as much of the system as possible in order to detect interface errors.
Weaknesses of a “classic” end-to-end test
Preparing a classic end-to-end test is usually a very expensive business. If it is also going to be used as a system test, the output values have to be based on realistic fault simulations, which means that every status has to be calculated separately or exported for every test case and every test set. Then, all the test cases have to be imported into the respective test plans in the same sequence. Creating the sequence when testing the logic is even more difficult. If, for example, a state change is triggered by a circuit breaker (CB) off command at just one end, the voltage and current signals at the other end of the line must also change. The distance between the test sets means that binary triggers can only be used to a limited extent. Precise time sequences must also be known so that these sequences can be created with time triggers.
Furthermore, all the test engineers involved must be equally familiar with the testing procedure. They must all know which test is to be carried out to ensure that the correct sequence is implemented simultaneously at all ends. This is often a source of errors. To evaluate whether the system has passed the test, the results from the individual ends have to be communicated by telephone, which means a single test can take several minutes. If the system fails the test, then modifications may have to be made to the test sequence, a process that is extremely cumbersome and error-prone if done by phone.
The Right Tool Makes all the Difference
Three core functions have been combined to create innovative testing software to improve the end-to-end test process.
- Transient power system simulation to calculate the test variables.
- Central control of test sets from a single PC.
- Iterative closed-loop as a patented solution for testing distributed logic.
Simulating the power system has two benefits. A system test based on power system data can pick up errors in the settings. The integrated power system simulation also saves a huge amount of time and greatly simplifies the preparation and execution of an end-to-end test. In the best-case scenario, the only data that need to be entered are the primary line impedance, the transformer ratios and, if desired, the short-circuit currents on the busbar. Then, all that needs to be done for the individual test cases is to create a fault at the required point and define its evaluation criteria. This takes no more than a couple of minutes and only needs to be done once due to the fact that the test sets are being controlled by the main application.
A “main application” in this sense refers to a PC-based application that is controlling several test sets in a time-synchronised manner (Figure 1). The integrated power system simulation correctly calculates the signals for all ends simultaneously at the moment of execution (Figure 2). The signal paths are recorded on the respective test sets and the synchronous starting time for all the sets is defined. On completion of the test, the test system fetches the recorded binary traces (for example, the off command) from all the test sets and evaluates them. One test engineer can initiate the entire process by pressing the Start button – no different to the testing of a single relay. Not only is the test evaluated immediately, a comprehensive test report is also produced. Should the test fail, necessitating a modification, the on-site test engineer can move the fault and repeat the test immediately.
The connection between the PC and the test set can be established directly or via a simple internet connection, in which case another PC connected to the internet at the remote end will also be required. However, this will only permit access to the connected test set via a password-protected Cloud connection from the main application. All the benefits remain though. (Figure 3).
Under no circumstances should testing of the logic be neglected. The specially developed iterative closed-loop algorithm significantly reduces the complexity of the logic test, something that is exemplified in the testing sequence for an autoreclosure. As before, the user picks a fault on the line. When the fault currents are output, the relays respond after a specified time with an off command. As the test sets are distributed, it is not possible to respond quickly enough with new signals on all ends. The application therefore starts the next iteration, beginning with the same fault currents. As the same trip times are expected, a command to open the CB was added to the sequence in advance. Once the trip occurs, the relays respond with a close command. The next iteration starts. This contains the fault, the trip and also the closing of the CB. The iterative closed loop repeats the process automatically until the complete autoreclosure sequence has been tested. The test engineer does not have to define the pause times, or even whether it is a single-pole or three-pole autoreclosure. Any faulty logic or coordination is detected immediately.
Preparation and execution of system-based end-to-end tests
An end-to-end test remains logistically complex, despite the immense improvements in the tools. It is, therefore, important to make good use of valuable time. This means creating and maintaining a checklist, as shown in this example:
- Verification of the power system data: do the simulated short-circuit currents approximate to what was expected?
- Is the protection concept sufficiently familiar to ensure that the response can be correctly evaluated and tested?
- Are an adequate number of test sets available with the required licenses and firmware?
- Are enough test leads, plugs and cables available?
- Is the cable for the GPS antenna long enough? (We recommend the use of GPS antennae with RJ45 connections, as random Ethernet cable drums can be used.)
- Is the cell phone charged?
- Are the test sets connected?
Over recent years, this innovative testing solution has detected many faults and saved commissioning engineers a great deal of time. An end-to-end test should, therefore, be an indispensable part of the commissioning of every line protection (differential and distance protection with signal comparison). It is also worth noting that a testing solution like this can also be used with other distributed protection systems, such as busbar differential protection, reverse interlocking, CB failure, etc., to name just a few. The transient simulation also enables transient ground fault protection, power swing blocking and other transient functions to be tested.