Test and verification of a busbar protection using a
simulation-based iterative closed-loop approach in the field
Christopher Pritchard | OMICRON electronics
christopher.pritchard@omicron.at
Thomas Hensler | OMICRON electronics
thomas.hensler@omicron.at
1 Introduction
Due to the high short circuit power apparent in transmission and large distribution substations,
dedicated busbar protection is in use. The impact of a busbar outage leads to high requirements
regarding speed and stability of a busbar protection. As a result of different busbar topologies within
substations, every configuration, and especially the logic, of the protection is unique. To guarantee
accurate performance, testing the whole busbar protection during commissioning is indispensable.
Test and verification of a busbar protection for complex busbar topologies with multiple busbars, bus
couplers, bays and feeders has always been one of the most challenging tasks for commissioning. A
single test device, injecting currents at only a single CT location, does not provide enough confidence
for the correct operation of the protection. Using a simulation-based approach, where the whole
busbar topology with all its isolator configurations is modelled within a test software, offers new
possibilities for all fault scenarios which are important to verify, such as faults inside and outside the
protected area or even faults in “dead zones” of the protection between a CB and its corresponding
CTs. With a test software, which can react to the individual CB trips with an iterative closed-loop
simulation, the real behaviour of the busbar protection, including breaker failure functions, can be
seen. This can be achieved with multiple GPS time-synchronized test devices.
2 Difficulties in traditional busbar protection testing
First of all we have to decide what we want to test before we can discuss how to test it. We are only
focusing on digital low impedance busbar differential relays. A modern digital busbar protection relay
is a multifunctional device that contains, as well as its main protection function, additional functions,
such as breaker failure and supervision, which also have to be considered.
The main protection function of a busbar protection is a differential measurement, which mainly
applies Kirchhoff’s law to identify faults within its area. However, because of the high requirements
on speed and stability, modern busbar protection relays decide to trip based on several separate
measurements. For example, a busbar protection relay can combine two measurements based on
the busbar topology and a third measurement, the check zone, that is independent of any isolator
state [1]. The differential measurements are usually stabilized with a percentage characteristic as
shown in figure 1. When the differential measurements indicate a fault within a busbar zone, the
busbar protection relay will utilize a trip logic which ensures that the fault is cleared selectively, for
example, by selectively tripping the breakers in the bays that feed the faulted busbar.
𝐼𝑑 = |𝐼1 + 𝐼2 … + 𝐼𝑛 |
𝐼𝑆 = |𝐼1 | + |𝐼2 | … + |𝐼3 |
1
Differential current I d
Tripping
zone
Stabilizing
zone
Id>
Stabilizing current Is
Figure 1: Percentage characteristic for a differential busbar protection relay
In addition, an important factor to consider is how these functions are distributed on physical devices
and how far they are apart. A reasonable answer for what to test looking at the busbar protection
would be:

Percentage differential characteristic

Measurement supervision

Tripping logic including circuit breaker failure protection
Looking at how this has previously been tested will show up the limitations of current solutions and
at the same time lead to the advantages of the novel approach of using simulation-based testing.
For testing a percentage differential characteristic, at least two currents have to be injected into the
busbar protection to be able to simulate a throughput and a fault current at the same time. Usually
modern protection testing software supports this by visualizing the characteristic and calculating the
currents based on a test point placed on the characteristic. For busbar differential protection this type
of testing can have its limitations. As already described, a busbar protection can have multiple
differential measurements, which can be set independently. In case they are active and set differently,
these differential measurements overlap. Very often therefore, the busbar protection relay gets reparameterized for the time of the test. We consider this as a very dangerous and questionable
approach. The risk of leaving the relay with the wrong settings and testing the relay with settings that
are not the final ones is very high.
Another challenge when testing the characteristic, or generally when injecting currents, arises when
the busbar protection system is distributed and the bay units are separated by longer distances.
Either very long test leads are needed or, if this is not possible, the test system has to operate several
distributed test sets. To avoid an unintentional differential current while testing, the injected signals
have to be time-synchronized over several test sets. Testing the characteristic of the check zone [2]
requires the injection of three currents to be able to test the selection of the stabilizing current.
Because of the limited amount of current outputs on the test sets, this is often achieved by looping
the current through the bay units. However, because modern low impedance busbar differential
relays support different current transformer ratios in every bay, this is not always possible.
Since there are a vast amount of supervision functions in modern digital busbar protection relays, we
are not going into detail on how they can be tested. They do, however, have to be considered when
testing the primary protection functions of the relay. They are often disabled while testing, to not block
the function under test. The risk of disabling or changing functions and parameters has already been
mentioned. For example, if the supervision detects and considers an analogue measurement to not
be plausible, it will suspend the calculation of the differential protection algorithm. This can be the
case when only a single phase current is injected into the current inputs of the relay. It is often
attempted using a single phase injection to be able to inject into multiple bay units with only a single
test set.
2
Testing the tripping logic is often the most complex part of a busbar protection field test. Due to all
the possible busbar topologies, almost every application of a busbar protection system is different.
Thus there is no standard way of testing the trip logic. To determine the correct bays to trip and clear
the fault, the busbar protection needs to know the exact topology of the busbar. Therefore, the busbar
protection needs to know the connection scheme and check the isolator position for all feeders,
sectionalizers and couplers during operation.
To test the trip logic of the protection system, the test system has to mimic the whole busbar power
system with all the binary information about the isolator states and the different bay currents in a
consistent manner. Consistent means, for example, that the analogue values are plausible and that
the current is only measured when the corresponding isolator is closed. Otherwise this can again
lead to measurement supervision, isolator supervision and breaker failure function influencing the
test.
Up to now this is achieved by setting up a spreadsheet with the different isolator states and currents
as columns and each test step being a consistent row. For the execution, the isolator positions are
mimicked according to the spreadsheet row by bridging the binary contacts at the bay units or by
operating the real switchgear to avoid breaker failure detection after every test. Due to the amount of
currents to inject and the possibility that the protection system can be distributed, this would lead to
an extremely complex test setup. A non-technical issue is that these spreadsheets are not very
comprehensible. Usually they are prepared by a test engineer transforming the connection scheme
into a spreadsheet. If the technician in the field is a different person and he has to understand a test
step, maybe to investigate an unexpected reaction, he usually transforms the spreadsheet back into
a connection scheme in his mind. This permanent mind mapping often makes the trip logic testing
very incomprehensible.
3 Requirements for a test system to test busbar protection
When we summarize the requirements for a test system used to test busbar differential protection,
we get the following list:

Scalable test setup. The amount of bays within busbars differ from substation to substation.
Therefore, the test setup should allow the control of as many test sets as needed to simulate
the required currents to inject.

Ability to operate multiple distributed test sets. Not only does the test system need to be able
to inject a large amount of currents, but it might also be required to inject them at different
locations separated by longer distances.

Fast, easy and consistent test step creation. By defining fault scenarios for example, the test
system shall ensure that all currents are consistent with the isolator positions. No disabling
or re-parameterization of the relay shall be required.

Communicate intention. Whoever is testing the busbar protection in the field should be able
to understand the intention of the test.
These requirements can be fulfilled by using a simulation-based approach. In such an approach, it is
possible to draw the busbar connection scheme as shown in figure 2. The topology can be defined
by operating the isolators in the scheme. The test steps are then defined by placing faults within the
scheme on the different equipment. By defining the position of the current transformers within the
scheme and defining their settings, with the possibility for different ratios, the simulation can calculate
all secondary currents within one test step simulation. From that point, the test software can then
start the injection on multiple test devices which have to be time synchronized.
3
Figure 2: Editor for drawing the busbar connection scheme
This approach is not relay function or element oriented. It focuses on testing the complete system as
a whole properly, before putting it into operation, and to verify that the busbar is protected under real
conditions. Therefore, it verifies the correct behaviour and if the busbar is protected rather than
validating that the settings have been correctly parameterized. The chosen test cases should verify
the following basic principles for the busbar protection system [3]:

Stability for normal operating conditions

Stability for faults outside the protected zone

High speed operation for faults inside the protected zone

Breaker failure conditions
Testing the characteristic is the opposite of a function oriented test. For example, using a simulationbased, application-oriented approach for testing the characteristic would be a misuse with other
disadvantages. It would just not be the right tool. If testing the characteristic is considered important
by the test philosophy, these tests can already be performed with existing test software. Nevertheless,
the possible need and danger of disabling or re-parameterizing must be considered. A requirement
that has not been stated, arises from the use of a simulation-based approach.
In many test steps it is important to react to the relay actions. This means, when a trip command is
sent by the busbar protection, the breaker has to open within the simulation and no current flow must
be simulated, the simulation must be consistent again. If this is not the case, it would be considered
as a breaker failure by the relay and scenarios that are waiting for actions after the first trip cannot
be executed. This capability of a simulation to react to the action of the system under test is usually
called real-time closed-loop. But because the test sets can be distributed, reacting to the relay actions
is often not possible.
A novel alternative to this, that would combine the advantages of reacting to relay action and injecting
with distributed test sets, is the use of an iterative closed-loop approach. When applying this approach
to a simulation with a busbar fault, the first iteration gets injected without any reaction to relay
behaviour. Nonetheless, the relay will react to the fault with a trip command which is recorded by the
test software. Because the relay should react when the same currents are injected, the next iteration
will start with the same waveform but this time the breaker opens after the trip time of the previous
iteration plus a constant circuit breaker trip time. When a second trip or close of the busbar protection
occurs, that has not been part of the first iteration but is part of the second iteration, a third iteration
is executed including both breaker events. This gets repeated till no new unknown trip or close
command has been sent by the busbar protection. At the end, the full sequence of events has been
recorded and the requirements are sufficiently fulfilled by keeping the advantages and easiness of a
distributed, simulation-based approach. Figure 3 shows an example with two iterations.
4
First iteration
Second iteration
Circuit breaker trip time
Figure 3: Exemplary iterative closed-loop sequence
4 Field test of a 380kV substation
In March 2014 we had the opportunity to prove the applicability of a simulation-based iterative closedloop approach in the field. The 380 kV part of a substation was re-commissioned after installing a
new protection system. While the test engineers at the utility commissioned the busbar protection the
way they used to do it, we had one extra day where we could use the simulation-based approach.
The substation and busbar is gas insulated (GIS). Figure 4 shows the connection scheme. The
busbar is a double busbar with a combi-bus [2], two segments and six bays. Two bays feed a 380 kV
overhead line each, one bay is the coupling field, one bay is for the sectionalizer, one bay is for future
extensions and one bay feeds a 350 MVA power transformer with a secondary voltage of 110 kV.
Except for the sectionalizer, each bay has one circuit breaker and one current transformer.
Additionally all feeder bays have a bypass isolator to transfer to the combi-bus.
5
BB1 A
C1
C2
C3
C4
C5
C6
BB2 A
BB1 B
BB2 B
Figure 4: Connection scheme of the 380kV busbar
As protection, a Siemens 7SS52 relay with one master unit and 6 bay units is installed. The master
unit and the bay units are installed within one cubicle. We used three test sets with six phase current
outputs each to inject into five bay units simultaneously. The test sets were synchronized with a GPS
grandmaster clock using IEEE 1588 PTP (Precision Time Protocol). The test sets recorded the trip
commands for all circuit breakers plus the alarms for a busbar fault on bus 1 and bus 2 on the main
unit. The test setup is shown in figure 5.
Figure 5: Busbar protection with master and bay units including test setup
6
5 Simulated test scenarios
As in a simulation-based approach, the test cases are defined in an application-oriented way. We
first have to define common busbar configurations under normal conditions. Based on the common
configurations, sensible test cases can be defined. We will show only a subset of test cases that are
required to commission a busbar protection as described here. These test cases will show the basic
principle of how to verify a busbar protection.
Within the default configuration for the busbar, the bays C1-C2 are connected to BB1 and C5-C6 are
connected to BB2. Both busbars are coupled and the sectionalizers are closed.
Stable operation under various high load flows
To alter the load flow between the test steps of a test case, the phase angle of one infeed can be
altered or varied. The possibility to vary arbitrary settings of the equipment is an important property
of a test software when you want to create many test steps quickly.
Internal fault on busbar section BB1 A
It is expected that the fault is cleared selectively by tripping the breakers in bay C5, C6 and the busbar
coupler. Also we want to make sure that no delayed trip commands are issued. That is why we
extended the simulation duration and used the iterative closed-loop feature to interrupt the current
flow in the busbar. If the current could not be interrupted, the breaker failure function would trip all
other breakers. In this test case the fault type is varied between the test steps. Figure 6: Transients
and assessment for an internal fault shows the transient signals and the measured trip times for the
test case.
Figure 6: Transients and assessment for an internal fault
Breaker failure function
To test the breaker failure function we reuse the same test case as above without the iterative closedloop turned on. The trip times in figure 6 show that after some delay, bay C1 and C2 are tripped as
well. Another important capability is to be able to define separate measurements that can be
assessed. This way the software can give an automated assessment. The last two test cases are
also repeated for faults on the other busbar sections of the busbar.
7
Figure 7: Measured trip times for a breaker failure scenario
Fault in the dead zone
A fault in the dead zone is a fault between the breaker and the current transformer of the coupler bay
[2]. A dead zone can only be avoided by having two current transformers within the coupler, thus
having higher costs. With only one current transformer the trip logic is not able to clear the fault in the
dead zone instantaneously when the coupling breaker is closed. The protection behaves the same
as if the trip of the coupling circuit breaker fails. With a delay all bays are tripped.
Stability against faults outside of the busbar
Again different fault types can be tested at different nodes outside of the busbar. In none of the test
steps is a trip is expected. It is also possible to place a fault behind a transformer connected at a bay.
As already mentioned, there are many other test cases that were executed in the field. Basically
every possible isolator and fault position should be considered when deciding test cases.
6 Conclusions
The field test proved that a verification of a busbar protection using a simulation-based iterative
closed-loop approach is feasible. Compared to the approaches previously used, the simulation-based
iterative closed-loop approach showed its benefits in terms of ease-of-use and speed. The high level
of effort required for building up a distributed test setup with multiple test sets was compensated with
a very fast and easy test execution. Considering the future with IEC61850 substations, where the
busbar protection only needs sampled value streams and GOOSE messages, the effort to set up the
test gets greatly simplified.
The simulation-based approach described can even be improved with the capability to simulate
current transformer saturation. Thus stability for close-in faults outside of the busbar, that cause the
current transformers to saturate, could be verified.
Overall it can be said, when choosing the test tool or deciding on how to test, it is important to first
have a look at what you want to test. When looking at a busbar protection with its complex trip logic
that is parameterized by specifying the application, for instance the busbar connection scheme, a
simulation-based iterative closed-loop approach is the right choice. This can be generalized even for
other applications such as distance protection with teleprotection schemes or auto restoration
schemes.
7 References
[1]
G. Ziegler, Numerical Differential Protection: Principles and Applications, Erlangen:
Publicis Publishing, 2012.
[2]
Siemens, SIPROTEC 7ss52x Manual, Siemens, 2004.
[3]
A. Apostolov and B. Bastigkeit, “Testing of Modern Bus Protection Systems,” in CIGRE,
Paris, 2008.
[4]
Z. Gajic, “Protecting Busbars,” PAC World, no. December, 2011.
8
About the Authors
Dipl.-Ing. (FH) Christopher Pritchard was born in 1982 in Dortmund / Germany. He
received his diploma in Electrical Engineering at the University of Applied Science in
Dortmund in 2006. He joined OMICRON electronics in 2006 where he worked in
application software development in the field of testing solutions for protection and
measurement systems. Currently he is responsible for product management for
application software for protection testing.
christopher.pritchard@omicron.at
Dipl.-Ing. Thomas Hensler was born in 1968 in Feldkirch / Austria. He received his
diploma (Master’s Degree) in Computer Science at the Technical University of Vienna in
1995. He joined OMICRON electronics in 1995 where he worked in application software
development in the field of testing solutions for protection and measurement systems.
Additionally he is responsible for product management for application software for
protection testing.
thomas.hensler@omicron.at
9