Cigre 764

34 Analysis And Guidelines For Testing Numerical Protection Schemes
Analysis and Guidelines

For Testing
Numerical Protection Schemes
-Final Report -
March 2000
12/26/2009 CIGRE 34.10

1
Acknowledgment
This guide was prepared on request of Study Committee 34 Protection and local Control by Working
group 34.10. The membership of this working group was as follows:
Convenor
Frank Wellens (Belgium)
Members
Jos Manuel Gallastegi (Spain)

Hans-Joachim Herrmann (Germany)
James A. Jodice (USA - assisted by Jay Gosalia)
Volker LeitLoff (France) - replaced Andr Giard
Stig Lidstrm (Sweden)
Peter Mller (Switzerland)
Toine Danen (Netherlands) - replaced Bas Verhoeven
Giuseppe Vianello (Italy)
Corresponding members
Luis Marcelo Funes (Argentina)
Alex Palamarczuk (Australia)
Raul Balbi Sollero (Brazil)
Bill Laycock (United Kingdom)
Mladen Kezunovic (USA)
GH (Graeme) Topham (South Africa)
The working group members wish to thank everyone who has contributed to this report.
12/26/2009 CIGRE 34.10

2
CONTENTS
1. Introduction ___________________________________________________________________ 7
1.1 Considered Tests and Vocabulary ____________________________________________________ 8
1.1.1 Test Classification For Numerical Protection Scheme Testing ______________________ 8
1.1.2 Certification versus Application Tests________________________________________ 10
1.2 About the Content ________________________________________________________________ 12
2. Analysis of Specific Items in Numerical Protection Influencing Testing __________________ 15
2.1 Data Acquisition and Processing ____________________________________________________ 16
2.1.1 Introduction ____________________________________________________________ 16
2.1.2 Long Term Stability of Components and Programmes ___________________________ 17
2.1.3 Sensitivity to Disturbances ________________________________________________ 18
2.1.4 Standardised Hardware ___________________________________________________ 18
2.1.5 Filters and A/D Conversion ________________________________________________ 18
2.1.6 Digital VT / CT Inputs____________________________________________________ 19
2.1.7 Validating the Algorithmic Process __________________________________________ 20
2.1.8 Reproducibility of the Process ______________________________________________ 22
2.1.9 Link Between Function and Component ______________________________________ 23
2.1.10 Availability of Values ____________________________________________________ 23
2.1.11 Minimum Requirements on the Protection for Testing ___________________________ 24
2.1.12 Demands on the Test/Evaluation Equipment___________________________________ 24
2.2 Programmable Input/Output Logic __________________________________________________ 25
2.2.1 Introduction ____________________________________________________________ 25
2.2.2 Logic Circuit Complexity _________________________________________________ 26
2.2.3 Single Input versus Multiple Input Energisation ________________________________ 26
2.2.4 Minimum Sense Time and Pickup Value of Inputs ______________________________ 26
2.2.5 Hysteresis of Inputs ______________________________________________________ 27
2.2.6 Reset Time of Outputs ____________________________________________________ 27
2.2.7 Verification of I/O Assignments ____________________________________________ 27
2.2.8 Minimum Requirements of the Protection for Testing ___________________________ 28
2.2.9 Requirements of the Test/Evaluation Equipment _______________________________ 28
2.3 Multi-function Protection - Integrated and Open Systems _______________________________ 29
2.3.1 Introduction ____________________________________________________________ 29
2.3.2 Testing of Multi-function Protection _________________________________________ 33
2.4 Self-checking Features_____________________________________________________________ 38
2.4.1 Introduction ____________________________________________________________ 38
2.4.2 Determining Internal Functions in a Numerical Distance Protection and Applicable Checks38
2.4.3 Effectiveness of Monitoring and Self-check Functions___________________________ 43
2.4.4 Reliability of Self-supervision ______________________________________________ 43
12/26/2009 CIGRE 34.10
3
2.4.5 Contents and Interval of the Maintenance Work ________________________________ 44

2.5 Digital Communication Ports and Remote Hardware and Software _______________________ 46
2.5.1 Introduction ____________________________________________________________ 46
2.5.2 Communication Protocol Testing: Compliance with Standards____________________ 47
2.5.3 Immunity Testing: Compliance with Existing Standards _________________________ 48
2.5.4 Testing Local Communication and Remote Software Quality as Part of the Approval
Procedure_____________________________________________________________________ 49
2.5.5 Communication Port Testing: Compliance with Standards _______________________ 50
2.6 Adaptive Protection _______________________________________________________________ 52
2.6.1 Introduction ____________________________________________________________ 52
2.6.2 Integration of the Adaptive Function_________________________________________ 52
2.6.3 Conditioning the Adaptive Feature __________________________________________ 53
2.6.4 Correct Adaptation_______________________________________________________ 54
2.6.5 System Controlled Adaptation______________________________________________ 54
2.7 Software Evolution Independent of Hardware _________________________________________ 56
2.7.1 Introduction ____________________________________________________________ 56
2.7.2 Demands on Software quality ______________________________________________ 57
2.7.3 Type Testing a Software Upgrade ___________________________________________ 58
2.7.4 Individual Tests on a Software Upgrade ______________________________________ 59
3. Guidelines for Testing Numerical Protection ________________________________________ 61
3.1 Functional Conformance Tests ______________________________________________________ 62
3.1.1 Introduction ____________________________________________________________ 62
3.1.2 Functional Conformance Test Programme ____________________________________ 62
3.2 Technological Conformance Tests ___________________________________________________ 65
3.2.1 Introduction ____________________________________________________________ 65
3.2.2 Technological Tests: Verifying Hardware Quality of Concept _____________________ 65
3.2.3 Technological Tests: Reliability Assessments__________________________________ 68
3.2.4 Technological Tests: Quality of Self-Supervision_______________________________ 69
3.3 Functional Performance Tests ______________________________________________________ 72
3.3.1 Introduction ____________________________________________________________ 72
3.3.2 Functional Performance Test Programme _____________________________________ 72
3.4 Scheme Performance Tests _________________________________________________________ 74
3.4.1 Introduction ____________________________________________________________ 74
3.4.2 Scheme Performance Test Programme _______________________________________ 74
3.5 Upgrade Type Tests _______________________________________________________________ 77
12/26/2009 CIGRE 34.10
4
3.5.1 Introduction ____________________________________________________________ 77

3.5.2 Upgrade Type Test Programme _____________________________________________ 77
3.6 Acceptance Tests _________________________________________________________________ 79
3.6.1 Introduction ____________________________________________________________ 79
3.6.2 Acceptance Test Programme _______________________________________________ 79
3.7 Commissioning Tests ______________________________________________________________ 81
3.7.1 Introduction ____________________________________________________________ 81
3.7.2 Commissioning Test Programme____________________________________________ 81
3.8 Periodic Tests ____________________________________________________________________ 84
3.8.1 Introduction ____________________________________________________________ 84
3.8.2 Periodic Test After 1-2 Years in Service ______________________________________ 84
3.8.3 Periodic Monitoring ______________________________________________________ 85
3.8.4 Normal Periodic Tests ____________________________________________________ 85
3.8.5 Condition-based Maintenance ______________________________________________ 85
4. Appendix: Different Approaches to Determining the Interval and Content of Periodic Testing 89
4.1 Interval Based Upon Reliability Analysis _____________________________________________ 90
4.1.1 Introduction ____________________________________________________________ 90
4.1.2 The Influence of Self-supervision on Availability, Security and Dependability________ 90
4.1.3 Calculation of the Influence of the Self-supervision on Availability ________________ 95
4.1.4 Risk Management of Protection Equipment ___________________________________ 97
4.2 Test Interval Based Upon Economic Considerations ____________________________________ 98
4.2.1 Economic Determination of the Interval for Periodic Tests _______________________ 98
4.2.2 Conclusions ___________________________________________________________ 101
4.3 The Influence on Skills ___________________________________________________________ 102
4.4 Zero Maintenance _______________________________________________________________ 103
4.4.1 Considerations on No Periodic Tests ______________________________________ 103
4.5 Condition-based Maintenance _____________________________________________________ 106
4.5.1 Introduction ___________________________________________________________ 106
4.5.2 The Condition-based Parameters ___________________________________________ 107
4.5.3 The Actions ___________________________________________________________ 110
4.5.4 The Rules _____________________________________________________________ 110
4.5.5 Conclusion ____________________________________________________________ 111
5. References___________________________________________________________________ 112
12/26/2009 CIGRE 34.10

5
Intentional Blank Page
12/26/2009 CIGRE 34.10

6
1. Introduction
In this chapter the considered tests are explained as well as the terminology used for them.
The goal of the work is also described.
12/26/2009 CIGRE 34.10

7
1.1 Considered Tests and Vocabulary

To understand the context of this report, it is necessary to have a preliminary knowledge of the test
classification vocabulary used. The 1986 Cigr-34 Report on testing [Ref 1] defined a vocabulary.
However, due to the specific differences for testing numerical protection, some modifications were
necessary. Table 1 of this document summarises the test classification vocabulary used throughout this
report.
1.1.1 Test Classification For Numerical Protection Scheme Testing

This chapter details the test classification for the testing of numerical protection schemes.
TYPE TESTS
Type tests are those tests performed once on a type of protection. This could be certification tests
performed by a certification organization or application tests on demand of a user. Certification
tests, are generally considered to be objective and are accepted by a wide range of users.
Application tests are user-driven and it is the users decision to perform a unique test or to accept
anothers test results. Thus, the definition "performed once" should be related to who has
performed the tests. For more information about the difference between certification and
application tests, see 1.1.2.
For numerical protection, it should be noted that the "type" specification covers hardware as well as
software, so each software version of a relay could be a different type.
Conformance Tests
The aim of these tests is to verify the conformance of the protection against specifications.
Most of these can be considered "objective" tests as they are generally related to standards
(IEC, ANSI, Cenelec, BS, etc.) or to function descriptions. There could be some confusion if
conformance to other than the mentioned standards is asked.
Functional Conformance Tests

These tests concentrate on verifying the functionality of the relay is as expected. It
focuses on verifying the general characteristics against specifications through analytical
signals. These tests are generally accuracy tests.
Technological Conformance Tests

These tests do not consider the relay's functionality. They consider how the relay
responds to external disturbances and internal failures. To a great extent, these
characteristics can be uncoupled from the type of relay and will be valid for the whole
family range but the possible exceptions make it difficult to exploit this item.
Practically, these tests cover:
The verification of the hardware quality (insulation, environmental, EMC, etc.)
The reliability assessment (ARM: Availability, Reliability, Maintainability)
The evaluation of the quality/depth of self-supervision.
12/26/2009 CIGRE 34.10

8
Performance Tests
The goal of performance testing is to verify the behaviour of the protection under real network
conditions. It includes all aspects, e.g. fault resistance, load, SIR-ratios, transient behaviour,
etc. It does not focus on how a certain function is performed in the protection, but on what is
generally expected from a function. Although these tests are more "subjective" they are closer
to reality. These are generally the most revealing tests on a protection. Since numerical
protection equipment often includes several functions, it is possible to make a distinction
between function tests and scheme tests.
Function Performance Tests

In this part, each function will be tested and evaluated separately. The performance of
the function itself should be examined in detail.
Scheme Performance Tests

The goal of Scheme Performance Tests is to verify equipment performance under
various conditions. There are a large number of combinations where all functions can
work together, so it is almost impossible to test them all. Therefore, the tests will be
performed on a limited number of real protection applications, with the equipment
schemes configured as they would be applied in those protection applications. If a
specific application is concerned, all auxiliary equipment can also be involved in the
tests. The results can also be used to determine the limits of the performance of a given
network characteristic (topology, source impedance, etc.). The results may be used by
the user to establish guidelines or instructions for setting the protection. Certification
tests are generally uncoupled from a real application. In this case, the scheme
performance tests should cover a worst-case condition.
Upgrade Type Tests

Theoretically, the complete type test programme should be performed for each version of the
relay. Realistically, this is impractical due to a very low profit/cost ratio. Therefore, smaller
"upgrade type test" programmes can be proposed. They are only a filtered version of the
complete type test programme and concentrate on two points: verifying the modified parts and
verifying that the unmodified part is not deteriorated by the modifications.
INDIVIDUAL TESTS
Individual tests are performed on each item of a type of protection. The intention is to verify different
aspects of the specific relay in its life cycle: receiving inspection, commissioning or in service.
Acceptance Tests
These tests aim to verify the quality of the delivery in relation to conformance with the order
and basic error-free functioning. These tests could be done at the factory, at the utility, or
during commissioning. Random samples may be tested instead of testing each individual
protection.
Acceptance tests for upgraded protection could vary, especially when a upgrade is retrofitted on
a protection already delivered. Attention should be given to verify the proper installation of the
software upgrade.
12/26/2009 CIGRE 34.10
9
Commissioning Tests
These tests are performed before the protection scheme is put into service. It involves all
aspects linked with the specific use of the relay: verification of all inputs and outputs (also
alarms), verification of application conformance, verification of setting conformance and
verification of the functioning. In addition, quality tests can be included.
Normal Commissioning Tests

These concern normal acceptance of a protection.
Upgrade Commissioning Tests

Commissioning of an upgraded protection could be partial, but can also include specific
aspects.
Periodic Tests
Periodic tests are the tests performed on the protection at specific moments during its installed
lifetime. On older protection, this was called maintenance testing. However, there is virtually
no real maintenance required on numerical protection, so these are now called periodic tests. If
tests are still necessary, they concentrate on the verification of the scheme performance,
verification of the supervision system, verification of the setting conformance and verification
of those components that are not supervised.
1.1.2 Certification versus Application Tests

For type testing, a distinction is made between Certification Tests and Application Tests. The
definition for each test type is given below, followed by an explanation of the difference between the
two test types that creates the distinction.
CERTIFICATION TESTS
Certification type tests are those tests that lead to an "objective" evaluation of a type of
protection. The results of Certification Tests are acceptable to a wide range of users,
independent of the application. It concerns, therefore: normalised tests under normalised
procedures and with normalised equipment. But in order to have an idea of the functional
behaviour of the relay, "standard" performance tests are added. Independent laboratories,
on demand of the manufacturer, generally perform certification tests. The result is a "Yes"
(certification) or a "No" for the type of protection.
APPLICATION TESTS
Application Tests are driven by the application. The results are not often shared with other
users because they are "subjective". They depend on many user-specific parameters: the
type of network, network operation and reliability requirements (protection demands). With
the emphasis on the application, the test programme consists mainly of performance tests.
The user generally requests these tests and the results are application dependent.
The normalised tests are, by definition, "objective". As long as users refer to the same
standard, it is difficult to make a distinction between certification and application tests.
12/26/2009 CIGRE 34.10

10
However, restricting certification tests to normalised tests would severely limit the value of
the conclusions made about a protection type. Therefore, application tests are added in the
certification programme. The goal of these tests is not to fully prove the application operation
under all conditions. The goal is to evaluate if the protection works properly in "sample"
applications when compared to the specifications, i.e. the emphasis is on the product. In
application tests, the emphasis is on the expected performance of the application.
Example:
A transformer protection with an inrush behaviour as specified cannot be rejected in
certification testing but can be rejected in application testing if the performance is not as
expected for the application.
In this paper, a distinction is made between certification and application testing to eliminate the
confusion that often exists about the difference. It is generally accepted that a certification
report should exist at the manufacturer's factory for a given type of protection. This is the
responsibility of the manufacturer.
Nevertheless, some users also expect that their own application is covered in the certification
reports. This is a misunderstanding. A manufacturer cannot be expected to cover all the tests
of all the applications of all their users. However, the manufacturer may perform user-specific
application tests at the request of the user, with agreement of the manufacturer.
The distinction made between certification and application tests in this paper is linked with the
importance level given to the various parts of the test programme. The difference between
Certification Tests and Application Tests is detailed in Table 2. Guidelines as to when to
perform each certification and application test during type testing is given in Table 1.
12/26/2009 CIGRE 34.10

11
1.2 About the Content

The question of how to test numerical relays, has become an important topic in the past several years.
The protection functions of the relay and the transient currents and voltages are still the same, but it is
the present state of technology that offers new possibilities and makes the number of functions in the
relay more complex. It is generally agreed that testing numerical protection should be different from
older techniques. Some basic aspects of numerical protections generally address this:
The data acquisition and processing is totally different from older techniques. It is not only
characterised by components but also by software algorithms. Moreover, non-analytical processing
systems could be used that are based on Artificial Intelligence techniques (Neural networks, Expert
systems, etc.).
Input/output logic is often programmable. This introduces a new degree of flexibility with the
consequence that additional, specific tests need to be performed on the protection scheme as a
whole.
The capacity of the microprocessor-based systems is rapidly increasing and generally precludes the
need for single function relays. Protection is evolving to a multifunction box that affects the
adequacy of the test programme. The function complexity of numerical relays has reached a level
where it is impossible to test every performance possibility. Consequently, the difference between
the function performance and scheme performance is increasing.
Self-supervision is a basic characteristic of numerical protection. It should allow a decrease in
periodic testing, and eventually eliminate it, if the protection supervision addresses the scheme as a
whole. Conversely, it also introduces the question of testing the self-supervision itself and of the
necessity to have an understanding of its depth.
Digital communication ports introduce a new way for protection technology to communicate with
the environment. The validation of this communication media is also a new area in protection
testing.
Numerical relays are very suitable for adaptive functions. Conditional changes should be
considered in the tests.
The first numerical developments have been subject to many software upgrades. This has created
some concern about validating software evolution independent of hardware.
The complexity of numerical relays is changing the method of testing. A general pattern can be seen of
a shift towards increasingly complex type tests and away from individual tests, particularly regarding
maintenance testing.
The need for a change in testing techniques can be seen and readily understood. However, these are
generalities that explain the differences. The problem is how to convert this understanding into a
concrete test programme. Utilities and manufacturers are searching for a unified approach to define
how these tests should be performed. The aim of this paper is to give a general understanding of the
specific aspects of numerical protection testing and to propose a testing concept.
12/26/2009 CIGRE 34.10

12
In the first part, a detailed analysis is presented on those features of numerical relays that affect the
adequacy of test procedures in place today. With this as a basis, the second part presents a means to
develop guidelines for protection testing. Practical guidelines will be given for determining test
programmes for the different types of tests:
Type Tests for functional, technological and upgrade verification
Individual Tests for commissioning and periodic verification
This paper is presented at a generic level, offering an abstract of protection types. The paper does not
offer specific and detailed programmes for each type of protection. There are several reasons for this
approach:
It is the function of Cigr to stimulate discussion and to offer guidelines so that detailed
investigation into the subject can continue based on a framework.
It would be an overwhelming task to investigate all types of protection in detail. Also, the
approaches to applying various types of protection (distance, differential, etc.) is very subjective for
each user.
Specific test programmes at different sites are determined by more than simply technical factors.
Factors such as the available test equipment and personnel, personnel skill level, cost, customer
demands, and objective. The user needs the flexibility to apply their individual philosophy.
Numerical techniques are advancing so rapidly that the offering of specific procedures would be
outdated almost before they were published.
Clearly, the objective is to provide users with a consistent framework with which to develop a valid
test programme that can be customised to individual practice.
It is also important to note that the guidelines are given from a users perspective. They do not
consider manufacturers' test validation during development. Manufacturers have the responsibility of
their products and should define for themselves the appropriate requirements to deliver a mature
product. That does not mean that manufacturers will not find the information in this report valuable
when developing their testing philosophy. Moreover, manufacturers are often confronted by users'
testing demands. One way of defining a manufacturers, or third party, tests are certification tests.
This is why the paper looks into the differences between certification tests and application tests.
Finally, it was necessary to address the specific problem of when to perform periodic tests. The need
and frequency of periodic testing is generally coupled with the depth of self-supervision available in
the protection. One of the basic problems we have looked at, is how to determine this depth. On this
basis, different approaches are possible to determine the schedule: maintaining reliability, reducing
cost, combining with other data and evolving to condition-based maintenance, and looking into the
necessary additions in order to evolve to zero maintenance. Although, we have not made a deep
theoretical study on this subject, some approaches are illustrated.
12/26/2009 CIGRE 34.10

13
Type Tests
Test Importance for
Certification Application
Conformance Tests
Functional Conformance Tests: Mandatory Some verification
- verifying characteristics against specifications points
- verifying performance against specifications
Technological Conformance Tests: Mandatory Some verification
- verifying hardware quality (insulation, climatic, EMC, etc.) against points
specifications
- reliability assessment (ARM: Availability, Reliability,
Maintainability) against specifications
- quality/depth of self-supervision against specifications
Performance Tests
Function Performance Tests: Important Important
- testing functions separately on all functions on used functions
Scheme Performance Tests: At least one Very important in
tests under realistic operating conditions with the relay configured as it sample specific cases
will be applied, either an actual or theoretical scheme
Upgrade Type Tests: Important Some verification
- verifying the modified parts points
- verifying global consistency
Individual Tests
Acceptance Tests (could be included in commissioning):
- verification of delivery (the product received complies with the one tested)
- verification of health of protection
- verification of proper software implementation (manufacturers verification procedure)
Commissioning Tests
(Normal) Commissioning Tests
- verification of all inputs/outputs and alarms
- verification of application conformance
- verification of supervision system
- verification of setting conformance
- verification of scheme response
- parts of standard commissioning tests: depends on whether an upgrade has been made
Periodic Tests
- verification of scheme performance
Table 1: Test Classification for Numerical Protection Scheme Testing
Certification Tests Application Tests
Goal Validating the protection as a Validating the protection for an
product application
Validity of tests More general More specific
Interpretation Numbers/facts Philosophical
Result Certificate for the product (Y) Application dependent conclusions
or rejection (N)
Table 2: Differences in Certification and Application Tests
12/26/2009 CIGRE 34.10

14
2. Analysis of Specific Items in Numerical Protection Influencing Testing
In this chapter the different items specifically related to the testing of numerical protection are
analysed and commented. This chapter gives in fact the justification for the test guidelines developed in
Chapter 3.
It is especially meant for those who want to know more about the background of the philosophy.
12/26/2009 CIGRE 34.10

15
2.1 Data Acquisition and Processing
2.1.1 Introduction
The typical layout of a digital protection system is as follows:
HMI Communication
Analogue A/D M D Processor 1 O

Filter U i Functions A u
X g t
Analogue A/D i Processor 2 p
Filter t Functions B u
a t
l
R
F e
i l
l a
Analogue t Processor N y
A/D
Filter e Functions M s
r
Figure 1: Typical Layout of a Digital Measuring System
The typical aspects of the measuring system can be characterised as follows:
After the A/D conversion, there is an independent division between the hardware (the processor)
and the software (the function)
The combination of parallel and serial hardware parts is fundamentally different from the older
techniques where the hardware redundancy was much more linked to the performance of the relay.
Considering the general characteristics, the testing of numerical protection can be analysed from two
perspectives: the hardware and the software.
The testing of a protection is very much influenced by the number of parallel hardware or software
elements. Parallel elements have a high degree of independent action, whereas serial elements
influence the chain of which they are a part. Concerning software, it should be noted that one
processor always works in a serial way even if the processes are functionally parallel. Although, a
more or less complex job scheduling or time slicing system could exist to handle independent functions
by one processor. Besides this, a protection can be built up of different processors, each of them
handling a part of the functions to be performed.
12/26/2009 CIGRE 34.10

16
Concerning the system hardware, the following characteristics are of importance:

Drifting is generally not expected on pure digital components, although there could eventually be
some drift on the A/D conversion.
There is a higher degree of integration of components linked to the use of chips and new
manufacturing technologies. This implies lower power supply consumption and the use of lower
voltages and consequently a theoretical higher sensitivity to disturbances.
The relationship between a function and a component is, at least for the user, not always clear and
could even be random in the concept. Therefore, it is sometimes difficult to test the hardware on a
function basis. Many components are supervised, which means that a hardware failure should be
detected by the system itself. Therefore, a special testing programme is not required. For more
details, see section 2.4.
Hardware modules could be standardised for different protection. The validity of one hardware
design concept could therefore be transferred to a large extent.
Concerning the system software, attention should be given to the following characteristics:
No drift is expected from software or algorithms.
The measuring system is an algorithmic process that can be very complex. Since no drift is
expected, the concern is a coding validation and not a maintenance problem.
The majority of experience in numerical processing shows that error-free programmes are
exceptional. Type testing should therefore also concentrate on searching for programme errors.
The algorithmic process is generally based on integers or real values and not on yes or no
evaluation. These values provide valuable information to the user and can influence the testing
method.
Some of these points will be considered later.
2.1.2 Long Term Stability of Components and Programmes

One aspect that influences the need for maintenance on electromechanical and static protection relays
is the drifting part of individual components that impacts their technical performance. Todays
microprocessor techniques have a high degree of stability. The main area that may change over time is
performance of the analogue to digital converter (A/D) even when no configuration changes have been
made after commissioning. Nevertheless, experience to date shows that A/D converters are both
reliable and stable.
Other components, including the CPU, DSP etc., are assumed stable over time. In this sense, stable
implies the memory will be maintained, the algorithm will perform correctly and no drifting of the
characteristics will occur. The behaviour of these components can be compared to computers that have
demonstrated high stability over long periods of time and use similar components.
In addition, for software, it is believed that there should be no real drifting, except as may be inherent
to the software, such as an unintentional looping process, or introduced to the software, such as a virus.
This drifting is conceptual and should be classified as an error. Section 2.7 addresses the problem of
12/26/2009 CIGRE 34.10
17
software validation. Drifting of software caused by hardware will generally be detected by the self-
supervision.
In conclusion, there is no need for periodic protection testing related to drift, except for the input stage,
if it is not self-supervised. Regardless of all the discussion on whether periodic testing is still
necessary, many users do continue the same test programmes as before: measuring the limits of the
characteristics as if there could be drifting. This is probably not the optimal approach.
2.1.3 Sensitivity to Disturbances

Due to the use of lower voltages, high clock speeds and high ohmic inputs, the sensitivity of numerical
protection to external disturbance is generally increased. Therefore, this problem needs special
attention during type tests. Disturbance tests generally relate to standards but, due to higher
environmental demands (e.g. GIS-stations) and the higher sensitivity of numerical relays, those
standards are changing very quickly and are becoming even more severe.
The consequence of a disturbance on a numerical system could be a permanent destruction (often

isolation problems) or a temporary disturbance of the system. In the latter case, it is preferred that the
relay will reboot correctly and resume its function. But in many cases, the relay will block and need to
be reset by hand. It is also important to check how the self-supervision reacts on a disturbance. Will
the user be able to analyse what happened to the relay afterwards? In order to do so, it is necessary for
the entire event to be well time-stamped in the event data. The time information, before and after the
reboot and the time of the reboot itself, should remain recorded so the data can be analysed after the
event.
The higher sensitivity to disturbances is normally countered by the improved design techniques of the
manufacturers. Therefore, this higher sensitivity does not generally lead to more problems. Moreover,
a decrease in external sensitive wiring also decreases the probability of disturbances. However, this
is not true in cases where numerical protection is combined with older classical wiring. Nevertheless,
special attention should be given to the sensitivity to disturbances.
2.1.4 Standardised Hardware

Due to the independence of software and hardware, manufacturers are building a family of protection
systems on a common hardware platform. Is it acceptable to validate a hardware platform on the basis
of a test on one member of the family? Theoretically, the answer should be:
Yes, if it concerns pure hardware matters, for example vibration or seismic tests.
No, if the software is involved, for example performance of the processor.
From the practical side, such a philosophy is conceivable from the users perspective (application type
tests), but not for certification. Indeed, certification concerns the whole protection and its
functionality.
2.1.5 Filters and A/D Conversion

Numerical relays are based on several filters. We can classify these as analogue filters (hardware) and
digital filters (software):
12/26/2009 CIGRE 34.10

18
A common hardware filter is the analogue anti-aliasing filter1. This filter is necessary to prevent
aliasing of the signal due to the sampling and windowing. If not present, higher frequency signals
might be seen as a lower frequency and disturb the measurement. The hardware filter is not often
supervised, thus testing of this filter is necessary.
Software filters are used to transform the sampled signals into meaningful values for the algorithmic
process, e.g. phasors of nominal frequency. These filters are normally supervised via the
algorithmic process and are analysed in section 2.1.7. It is indeed hard to dissociate the result
(phasor) from the filtering capacity.
Testing software filters is a primary concern for type testing because they depend on an algorithm and
do not drift over time. Analogue filters can fail and should therefore be periodically tested. For these
tests, injecting harmonics is suggested since basic periodic test signals generally do not detect failures.
A/D conversion is generally limited in dynamic range. The digital values are often integers with a
specific number of bits. For example, 12 bits give a dynamic range of 212 , or 4096 states. This is too
limited to cover the dynamic range of the current with sufficient accuracy. Indeed, the load range
(0-2*IN) should be accurate, but also short-circuit currents should be covered (100*IN). Therefore, a
second range amplifier is often used. Since this component is not activated under normal conditions, a
periodic test of the high range is advisable. Today, however, a dynamic range of 16 bits is often used
which makes the second range superfluous. A/D conversion is also characterised by the sampling of
the signal. As indicated above, this sampling introduces a filtering effect and should be linked to an
appropriate filter in order to produce the correct values.
Effective testing of the sampling conversion creates some demand on the generated signals of the test
equipment, certainly when the generated signals are synthesised values created through A/D
conversion. First, it is clear that the generated signals should use a sampling rate that is at least 2 times
higher than the sample frequency of the equipment under test. Secondly, it is necessary to test the
protection with harmonic content in order to evaluate the effectiveness of the filtering. During type
testing, this will be achieved through the functional conformance tests and also via the performance
tests with the use of transient signals. During individual testing, harmonic testing is only necessary if
the filtering is not self-supervised.
The sampling frequency is often adapted to the net frequency. This is especially apparent when a wide
frequency range should be covered such as with generator protection. The consequences should be
clear in the performance test results of the relay at other frequencies. Special attention should also be
paid to harmonic testing in order to evaluate the effectiveness of the aliasing filter. Indeed, the
bandwidth of the filter should be adapted to the variable sample frequency.
2.1.6 Digital VT / CT Inputs

In the coming years, it is likely that conventional or non-conventional voltage and current transformers
with digital outputs will become readily available on the market. One method is with VTs and CTs
that provide a low level output (e.g. nominal currents in the range of mA and nominal voltage in the
range of a few volts). Other types of VTs and CTs provide digital outputs. The interface is now serial
1
Nowadays, digital anti-aliasing filters also exist. This is especially interesting when a variable sampling rate is used as the
filter is tuned to it.
12/26/2009 CIGRE 34.10
19
and defined by a protocol. Case 1 requires low voltage level interfaces. Case 2 requires a protection
device with one or more serial interfaces with the nominal current defined by bits. The standardising
of the corresponding interfaces between CT/VT and protection relays has begun.
If protection with digital voltage and current inputs are tested, it is clear that some tests have to be
changed with respect to the numerical protection against what exists for conventional analogue inputs.
Since the interface is not defined, it is difficult to give specific test proposals. However, a list of items
which could be tested or which have to be regarded can be given:
A simple way to test the digital input would be to create an input signal from a recorded or
simulated event, feed this signal into the protection and obtain a read-out from the internal fault
recorder of the protection. A special test device with a serial interface and protocol simulation is
necessary. In case of analogue inputs, the tests can be done with a low level signal generator.
If the information of all measurement transformers is received by one digital input, the consistency
of the incoming data should be checked by the protection. This can be done using similar test
criterion to those discussed in the chapter concerning self-supervision for the analogue input check.
A possible test of this feature could consist of artificially creating incorrect digital signals and
verifying that those are detected by the protection.
In numerical protection with analogue inputs, the sampling frequency is often adjusted to the
frequency of the network in order to have a constant number of samples per period. Using digital
inputs, this adjustment of the sampling frequency may not be provided, or at least not controlled by
the protection. For this reason, the behaviour of the protection relay in its nominal frequency range
should be tested for slow variations of the network frequency and for fixed network frequencies.
It is expected that the communication between digital measurement transformers and the relay will
be "one-way", i.e. the transformer sends the information to the protection without receiving any
signals from the protection. However, if there is any communication directed from the relay to the
transformers, this communication also has to be tested in an appropriate way.
In the transition phase, there may be a co-existence between digital measurement transformers and
protection with analogue inputs. This can be done by recreating low level analogue signals from the
digital data in order to operate the numerical protection with analogue inputs. In this case, if the
A/D converters are a part of the relay, they should be monitored by the self-supervision function.
The efficiency of the self-supervision for the A/D converters then also needs to be tested.
This test requires a system that is able to create a digital output signal corresponding to the digital
signals coming from the digital CTs and VTs or, in the other case, to provide outputs with low level
voltage signals.
2.1.7 Validating the Algorithmic Process

The validation of the algorithmic process becomes an increasingly important factor as the protection
becomes increasingly complex. In this chapter, we are solely concerned about the algorithmic process
of one function. The multi-function aspects, and the problems related to adaptative relaying, are
handled in their respective chapters. Note that an extensive validation of the algorithmic process is
only a concern for type tests because the process will not change over the normal lifetime of the
protection.
12/26/2009 CIGRE 34.10

20
The questions concerning validation of the process include the following:

Is the function performing according to the specified characteristics or description in the manual?
This question is mainly of importance for certification.
Is the function performing as needed for the application?
This is mainly a question of the user, and the most important one for application type tests.
These questions should be considered from a perspective as close as possible to actual operation under
power system conditions, including dynamics and time demands, and normal use of the protection.
Pure algorithmic validation on a computer is certainly a very good tool for the manufacturer to use in
the development stage, but it is not appropriate for certification or application tests. Indeed, the signals
undergo different transformations before they are algorithmically treated. Neglecting these effects
could have a considerable impact on the validity of the algorithm. For example, neglecting the effect
of input CTs on a saturated signal of the HV-CT could lead to incorrect filtering methods.
The above refers to conceptual validation. Conceptual validation is linked to the theoretical
background that is used. Implementation validation should also be considered. This is related to
detecting errors (bugs). In addition, these tests should be performed as close to true power system
conditions as possible, although there should also be a concern to detect that the algorithm remains
stable under non-realistic conditions for aspects of security. Some random tests could help determine
the validity of the algorithm.
Functional conformance tests are linked to normalised testing to determine the limits of characteristics.
Some problems could arise for new relays, since the algorithmic approach may allow other methods to
achieve proper operation beyond the generally recognised characteristics. For example, how should
the expected accuracy of distance protection characteristics be interpreted if the protection is based on
generic rules that do not include a characteristic?
In particular, some specific problems could arise in validating algorithmic processes that are based on
artificial intelligence. In this case it is often not possible to base the evaluation on an analytical
analysis because the algorithm itself is often non-analytical. Functional conformance testing
(verifying characteristics against specification) could, in this case, be impossible because the
characteristic of the function itself cannot be clearly specified. Performance testing becomes very
important in this situation because the focus is to verify that the desired operation is obtained and not to
verify how a particular function is achieved. The question however is: what will be the acceptance
boundary for type testing, especially for certification testing? Will the function be accepted if it works
in 95% of the cases or not? Moreover, if the performance behaviour is obtained via a learning
process, it is important that the performance testing programme is totally independent from the
learning programme. Also, if the training process continues during the use of the protection1, it should
be accepted that the functional behaviour of the relay changes over its lifetime. The initial type test
could therefore become worthless at some time.
Example:
2
This means that the good or bad behaviour of the protection should be confirmed at each learning step.
12/26/2009 CIGRE 34.10
21
An inrush stabilisation that is achieved via second harmonic level blocking can be tested for
functional conformance by verifying that the blocking becomes active at the pre-set level. This does
not mean however that the performance of the function is as wanted (blocking on inrush). An
inrush detection that is achieved via non-analytical artificial intelligence techniques will not
necessarily be defined by a characteristic. Only the performance of the function (blocking on
inrush) could be specified. In this case only performance tests can be executed.
It should be noted that the importance of the algorithmic process is not limited to type testing.
Although it is not the goal to test the process through the other test programmes, the influence will
always be present. Some attention needs to be given to the test equipment used as the following
example illustrates:
Some types of numerical protection, in particular distance protection, use the transient signal in
order to initiate a "fast" trip command for close-in faults. On the other hand, test sets that generate
steady-state signals for the test of these types of protection, often do not correctly reproduce the
transient phenomenon. The signals "jump" from one steady-state (corresponding to the unfaulted
system) to another (corresponding to the faulted system), without checking whether basic physical
laws (such as continuity of current) are verified. In this case, the transient state does thus not
properly exist in the transition, or it does not correspond to a transient state of a "real" network. It
is evident that misoperations can occur when applying these signals to protection that operates on
transients.
Therefore, compatibility between the test set and the protection to be tested should be verified.
2.1.8 Reproducibility of the Process

Software is generally recognised as generating a very reproducible result because it performs tasks in a
serial way. Performing the same process multiple times with software should generate the same result.
This is also applicable to numerical protection, but care needs to be taken when defining the same
process. Introducing the same fault sequence two separate times into a protection will not necessarily
create the same software process. This is due to the following reasons:
The sampling process of the relay is generally not synchronised with the analogue inputs. This
could have a considerable influence on the result if relatively low sampling rates are used, or when
the measuring windows are succeeding instead of gliding.
Interruptions may occur in the function because of, what may seem at first, to be an invisible
condition.
The consequence is that it is necessary during type tests to repeat certain test points several times. This
is certainly the case when non-pure sine-wave signals are present in conditions such as inrush,
saturation, or an intermittent fault.
Special attention is also needed when the tests do not simulate true power system conditions as was
illustrated in the preceding chapter. In this case, the results obtained should be evaluated in their
context or the test reproduction should be adapted.
12/26/2009 CIGRE 34.10

22
2.1.9 Link Between Function and Component

The link between function and component is an important factor because the validation of a component
is often confirmed by the functional response. In this way, it also determines the contents of a test
programme. This problem mainly concerns individual tests.
Example:
In previous measuring techniques, there was a link between the test programme and the number of
phase and zone elements. A full-scheme relay has separate measuring systems (hardware) and
consequently each of them should be tested. In digital techniques, the separate measuring systems
still exist related to software, but are generally performed by one component. To verify the
component, it is no longer necessary to verify each phase and each zone.
The above example shows that the link between function and component has changed and that testing
procedures need to adapt. Therefore, the user needs to know which component performs which
function. Since this link is sometimes arbitrary, there may be a problem in verifying it. Fortunately, in
these cases, the component often is self-supervised and testing is not necessary. Some parts could
remain without self-supervision, but generally there is a clear link between function and component.
2.1.10 Availability of Values

The permanent availability of the measured values is an important advantage for simplifying the
individual testing of a protection for several reasons:
Validation of the input stage of the protection scheme:
A simple look at the measured values could be sufficient. Also, derived values such as impedance,
in the case of distance protection, can be very helpful.
Searching for the appropriate setting:
The ability to see the test point in comparison with the setting overcomes the disadvantage of
numerical relays not being able to change settings with flexibility during injection. Indeed, a
numerical setting should first be introduced, accepted, and made active before it takes effect.
Also, fault values, that are stored in fault and event recording, can provide great assistance in the
analysis of the protection behaviour and allows it to be evaluated in a proper way. See also the
appendix on Condition-based Maintenance.
12/26/2009 CIGRE 34.10

23
2.1.11 Minimum Requirements on the Protection for Testing

The following special requirements can be given in order to thoroughly test the measuring system of a
numerical protection.
Requirements Reasons Type of Testing

Indication of the hardware Extrapolation of technological Technological Conformance Tests
family. tests to the complete hardware
"family".
Description of the hardware- Allows the ability to determine Technological Conformance Tests
software organisation. redundancies in the protection. (ARM)
Individual Tests
Describing algorithmic models. Allows comparison (conceptual Technological Conformance Tests
validation) Performance Tests
Availability of measured values Partially validating A/D All tests.
with HMI conversion via HMI-reading
2.1.12 Demands on the Test/Evaluation Equipment

Demands on the Reasons Type of Testing
Test Equipment
Harmonic injection Verifying filter capacities (anti- Individual - Periodic Tests.
aliasing)
Special Equipment for Sensitivity to disturbance of numerical Technological Type Tests
normalised disturbance tests protection
High level and precise Validating the algorithmic process Function Performance Type
simulation capacity (Network Tests
transients, CT saturation, CVT
transients)
Signal outputs corresponding to Testing protection adapted for use on All tests
new standards (future) digital VT/CT inputs
12/26/2009 CIGRE 34.10

24
2.2 Programmable Input/Output Logic
2.2.1 Introduction
Programmable input/output (I/O) logic circuits are present in many available numerical relay designs.
In these relays, the user can customise relay logic using inputs, analogue measurements and outputs to
suit the application. Logic circuits process digital inputs to control digital outputs within the relay. A
typical block diagram of a modern digital relay is shown in Figure 2:
Measuring
Analogue Inputs
Circuit
Input 1 Output 1
Input 2 Output 2
Input 3 Logic Output 3
Circuit
Input N Output N
Figure 2: Input-Output System

In other numerical relays, input and output assignments may be pre-set in accordance with the
protection application. One technique for programming inputs and outputs is called masking or
marshalling. Figure 3 shows a simple example of the masking technique for eight inputs and eight
outputs in a numerical overcurrent relay.
Logic
Input Mask
0 0 0 0 0 0 0 1
Output Mask
& 0 0 0 0 0 1 0 0
I>Is
Figure 3: Input/Output Masking or Marshalling

In Figure 3, the I/O masking and relay logic indicate that if Input 1 is active, and current I is greater
than IS, then the logic circuit operates Output 3. The same input and output may be used multiple
12/26/2009 CIGRE 34.10

25
times throughout the logic of the relay. A number of aspects unique to relay designs with
programmable I/O logic and how they influence testing are noted below.
2.2.2 Logic Circuit Complexity

For a simple input/output device such as a reclosing relay, tests may be simple to ensure all inputs and
outputs are working in accordance with the specifications. Inputs and outputs could be monitored to
ensure that only the correct inputs and outputs change state. All outputs should be monitored to
confirm that only those outputs that are intended to operate do change state and that those not intended
to operate do not change state. For more complex relays, such as multi-function distance relays or
generator protection relays, a simple test of inputs and outputs may not be sufficient. A detailed check
of the logic needs to be performed in order to confirm proper operation.
Logic elements may include "OR, AND, and NOT gates", along with timers. Performance tests should
be performed to ensure that the software is working properly to implement the users settings. Logic
tests should include the following to determine proper operation:
OR elements work independently
AND elements work inter-independently
Combination of OR and AND elements work correctly
Inverting elements (NOT functions) work correctly. The previous tests should be run with the
inverted logic inputs.
Timers - operating and resetting times - are working correctly.
The complete scheme should be tested to confirm it operates properly. The previous tests confirmed
the correct operation of each input and output of the relay as a unit. The complete scheme test should
include as many interconnected components as possible. Since there are many different configurations
of a logic scheme, a typical scheme, with as many components as possible, should be tested to ensure
functional conformance. Once the user decides on a particular scheme for the application, it should be
completely tested for both functional and commissioning tests.
2.2.3 Single Input versus Multiple Input Energisation

The same input and output may be used multiple times throughout the logic of the relay. Various
outputs may be operating depending on the state of the logic input and analogue energising quantity. It
is important to test the relay with multiple input energisation to ensure that the logic is working as
intended. This will show if there is a time difference in the relay performance with the energisation of
a single input versus the energisation of multiple inputs.
2.2.4 Minimum Sense Time and Pickup Value of Inputs

Numerical relays employ input filters and sensing circuits to prevent the relay from responding to
transients and noise signals. When an input pulse is applied for less than the minimum sense time, the
input should not pick up. Tests should be conducted to confirm the correct input signal detection for
all inputs. Similarly, when an input is applied that is below the minimum operating value, the input
should not pick up.
12/26/2009 CIGRE 34.10

26
2.2.5 Hysteresis of Inputs

Some protection logic input circuits employ hysteresis. Hysteresis requires a lower level energising
quantity to reset the input. This feature avoids accidental reset of an input due to contact bounce or
signal discontinuity. Tests should be carried out to check the hysteresis on relay inputs. The relay
logic input should remain energised until the level of the input signal, or duration of the signal, is
reduced below a specified level.
2.2.6 Reset Time of Outputs

The reset time of the output should be checked against the specification. This test should be repeated
for each individual output and performed one at a time. The test should be repeated while de-
energising all the programmed outputs at the same time. This will check if there is a time difference in
the relay performance between the de-energisation of a single output versus the de-energisation of
multiple outputs.
2.2.7 Verification of I/O Assignments

The testing of programmable I/Os must include the verification of all input and output assignments
against the setting sheet.
The response of logic inputs and outputs to input energisation needs to be checked to ensure the
following:
Verification of the programmed logic, i.e. all inputs are interacting correctly with the programmed
logic.
To confirm that the operating time is correct and that no contact race or sneak circuit condition is
present.
The proper operation of all outputs in the logic should be checked to ensure the following:
Each output should tested for proper operation in the scheme(s) in which it is located.
The rating of all devices connected to the outputs should be checked to ensure that the ratings do not
exceed the relay output ratings specified.
The timing of the output contact should be checked for correctness.
Each of the outputs should be exercised by applying an appropriate energising quantity to the relay
to ensure the complete output logic operates correctly.
Ensure that only the outputs that are programmed to operate are responding and that the outputs that
are not programmed to operate are not responding.
12/26/2009 CIGRE 34.10

27
2.2.8 Minimum Requirements of the Protection for Testing

Requirements of Protection Reasons Type of Testing
Simple method of representing Unambiguous identification of All tests
user-programmed logic functions the active programmed logic
Activation of an Input logic with Verifying Inputs and logic Functional Conformance Tests
time-stamp. Commissioning Tests
Periodic Tests
Activation of an Output through Verifying Outputs Functional Conformance Tests
the programmed Output logic. Commissioning tests
Access to internal logic variables Activating logic conditions Functional Conformance Tests
internally Commissioning tests
Activation of pre-programmed Verification of the proper Functional Conformance Tests
logic functioning of pre-programmed
logic.
2.2.9 Requirements of the Test/Evaluation Equipment

Requirements of Reasons Type of Testing
Test Equipment
Multiple and programmable Simulating working conditions for the Functional Conformance
time-delayed logic outputs on programmable logic. Tests
Pick up or Drop out to be Commissioning Tests
available.
Configurable outputs for make, Simulating working conditions for the Functional Conformance
break or changeover contact programmable logic. Tests
configuration Commissioning Tests
Output contacts voltage rating to To check various logic for the whole Functional Conformance
be at least 250 V DC/AC and scheme Tests
0.5 A AC/DC Commissioning Tests
Input wetting voltage for logic To check relay contacts are working Functional Conformance
input to be at least 12 volts or 20 correctly Tests
mA DC to break down silver Commissioning Tests
tarnish or copper oxide of relay Periodic Tests
contacts.
Isolated logic I/O To series and/or parallel I/O for system Functional Conformance
simulation Tests
Commissioning Tests
Periodic Tests
Time controlled logic inputs To measure time response of the All tests
activated logical inputs
Proper combination of logic To check logic for protection scheme Functional Conformance
inputs and ensure no contact race problem Tests
Commissioning tests
Periodic tests
12/26/2009 CIGRE 34.10

28
2.3 Multi-function Protection - Integrated and Open Systems
2.3.1 Introduction
2.3.1.1 Basics of Multi-function Protection

To better understand the following discussion on required tests, it is necessary to define the multi-
function protection. Figure 4 shows the basic structure of a multi-function numerical protection. It
consists of hardware and software modules. The hardware is usually engineered and configured by the
manufacturer according to the protection type and to the user specification. The installed software
depends on the protection functions. They can either be fixed in the protection, or they can be selected
from a options defined by the ordering code or by the user. The final configuration is usually done by
the user.
HMI Communication
1 Downloaded from Serial 1

HMI: Comm.
Function and signal
2 configuration, settings 2
Digitized input I/O Logic

values values I/O's
Library of Funct.n
functions
n Funct. 2 Diagnostic m
and
Funct. 1
supervision
Figure 4: Structure of a Multi-function Protection (from the CIGRE-Report 1996: 34-202)

The typical features of multi-function protection are:
Hardware
the type and quantity of analogue inputs for currents, sensitive currents, voltages or special signals
(dc-voltage, temperature) depends on the hardware configuration
the quantity of binary inputs (e.g. opto-coupler with different pick-up levels) and binary outputs
(e.g. alarm and trip relays) depends on the hardware configuration
local indication via LED and/or LCD
serial or parallel interfaces for communication (e.g. with a personal computer, a control station or
SCADA-system) depends on the hardware configuration and the communication protocols of the
manufacturer, the user; and inter-relay communication
serial communication with digital data acquisition systems
processing unit (single or multi-processor system) with the necessary components (EEPROM,
Flash-EEPROM, RAM or NV-Ram)
12/26/2009 CIGRE 34.10

29
Software
The software determines the function of numerical relays. There are different software parts in
numerical protection. More than one protection function is standard. They perform the main and
emergency back-up protection requirements. All necessary protection functions for one protection type
can be in one device (e.g. for motors, generators, etc.). Figure 4 shows this with the library of
functions. Many other additional functions are also included in numerical relays. They are necessary
and useful for relay reliability, commissioning, control and supervision purposes in addition to network
fault analysis. Examples of these additional functions are:
self-monitoring (hardware and software failure detection)
metering (V, I, P, Q, cos, f)
event recorder (operational events and fault events)
disturbance recorder (e.g. 8 channels with a disturbance time of 3 sec.)
communication software (for HMI and control systems, inter-relay communication)
local HMI (display and keypad)
control functions in combined devices (protection and control, e.g. in medium voltage applications)
Figure 5 shows the typical software structure of numerical relays. The central part of the software is the
system software. This controls the task priority and guarantees the operating time of the relay (e.g.
shortest tripping time).
For on-line parameters, the communication software must be activated. This transforms the decimal
data into internal data format. The settings are stored in the memory (EEPROM). Data acquisition
(sampling of analogue and binary input values) has the highest priority with the data stored in non-
volatile RAM (e.g. battery buffered).
The protection functions use the programmed algorithm to calculate the required values (e.g. rms of I,
V; fundamental components of I, V, R, X) and compare them with the settings or characteristics. The
result can be an alarm or a trip. The interface or communication software is responsible for the
signalling.
The quantity of protection units needed for an application depends on the numerical performance of the
relay hardware and the additional in-built functions available. From the user's perspective, the
different functions need to be viewed separately.
12/26/2009 CIGRE 34.10

30
Display, PC
Substation control interface
Measuring Parameterizing,
marshalling, commu-
nication
Data Calculation internal

acquisition parameter format
System software Memory of

Data storage (Task control) settings
Protection functions
1 ...n
Self monitoring
Interface software
Flow of data
Program call LED, binary inputs, relays
Figure 5: Typical Software Structure of a Numerical Relay
2.3.1.2 General Influence of Multi-functionality on Test Procedures

Compared to analogue static relays, a substantial increase in the amount of in-built functions can be
observed. The numerical and logical operations are performed by one or more microprocessors with a
multi-tasking firmware system. The task priority depends upon the intended function (accuracy,
reaction time, etc.) and differs from one manufacturer to another.
The real-time behaviour of the software becomes an important aspect of design consideration in
numerical relays. If software can be selected, or downloaded from a library, a mechanism must be
available to supervise the parallel running of various functions.
The discussed aspects in sections 2.1.2 to 2.1.9 are also valid for multi-function relays. It would take
an unrealistic amount of time to check all the combinations of functions with different data (settings,
inputs values, blocking signals, etc.). Dividing the tests into different parts is a useful way to perform
protection testing (see section 1.1.1). The testing of each separate function with static and dynamic
signals is necessary, but scheme testing with the proper test equipment becomes increasingly important
for transient tests, additional communication interface tests,.etc.
12/26/2009 CIGRE 34.10

31
During the development process, manufacturers devote a significant amount of effort on functional and
system testing. They employ the technology of power system simulation, static and dynamic test
methods and scheme testing with transient network analysers.
2.3.1.3 Discussion of Integrated and Open Systems

Different design philosophies are used by different manufacturers. The integrated or closed devices
are multi-function protection with a fixed software scaled for a dedicated hardware. In most cases, the
analogue inputs are fixed and connected with the software (refer to section 2.1.1 with regard to
measuring). Some manufacturers allow the user to select the software function via the ordering code
that also determines the fixed hardware. The manufacturer guarantees the real-time behaviour of the
protection. This means the relay is designed to include the maximum functions available by the
ordering code.
Real-time means that all functions can operate in parallel and the operation, particularly trip time, is in
accordance with specification. Additional functions operate at a lower priority and the repetition time
is slower. Similarly, the communication software can have a slower reaction time. When software
upgrades are installed in the relay, the operation must behave as before.
The availability of integrated logic functions are a move in the direction of open relays. The user can
generate their own logical signal with fixed protection software. For example: applying AND logic
gates with an additional time delay, or blocking a function through another logic gate. The engineered
logic must be checked by the user. For such applications, additional time must be taken during the
scheme test to prove the generated logic.
There is not a fixed boundary between open and integrated relays. If the term open relays is used, it
means the software is not absolutely fixed. A compromise between open and integrated systems can be
devices in which the software is loaded from a library or that some functions can be duplicated. The
software library is greater than the parallel running software. A special HMI-software must check the
possible combinations and give an alarm if the numerical performance is not sufficient. There are also
available numerical relays that have many standard measuring elements that are similar to the
protection functions. With an integrated logic, the user can accomplish logical combinations,such as
implementing timers and other elements. Some of these are described in section 2.2. The advantage of
flexibility also creates the disadvantage of increasing the chance of error and increasing the test time
and expense. With open relays the level of in-depth testing significantly increases because new
combinations of function are generated. The interdependency between the functions must be checked
to assess the impact on real-time behaviour. Additional tests during both function and scheme testing
are absolutely necessary.
Future generations of open relays will provide hardware and software tools to the user to generate a
numerical relay with its own functionality, similar to a Programmable Logic Controller. A library
contains all the protection functions, ancillary functions and logical elements needed for the user to
design a numerical relay for any application. One important question is: how to test such a device?
Presently, the manufacturer takes the responsibility for the majority of numerical relay testing. If the
test responsibility shifts to the user, the user needs to significantly increase its engineering staff to
12/26/2009 CIGRE 34.10

32
ensure the needed resources are available. The product responsibility needs to rest with either the
manufacturer or the user, but what is the practical situation with multi-function relays?
1. Many functions are contained in one device with a high degree of flexibility of combinations and
interfacing. Many parameters must be set (settings, marshalling, etc.). A misunderstanding of
setting methods and incorrect settings are possible possible with complex relays. It is necessary to
first test each function separately and then to test the combination of all functions. For the last test,
relevant practical data (e.g. typical transient faults) are recommended.
2. An ongoing development process to improve functions in the software or to correct software errors
produces new software versions. When the relay is upgraded with the new software, additional
testing must be performed to prove the upgrade and its impact on the existing protection function.
3. Development of new functions (e.g. logic, special fault records, protection functions) may be made
for a fixed hardware and system software configuration. This may be an option, with a revised
ordering code, of an existing device. The new function must be tested separately and also as part of
the scheme to ensure the new function operates properly and has no impact on real-time behaviour.
4. A new hardware configuration can be used in a standard relay (e.g. central processing board). This
means that new links (hardware driver) will exist between the hardware and the existing software.
The protection software may remain the same, or some functions can be added. The depth of testing
needed in this circumstance should be discussed with the manufacturer.
5. A standard protection relay with the same protection function, e.g. distance protection, may be
supplied with new hardware (processor, data acquisition, internal transformers) and an improved
protection software (new measuring algorithm).
2.3.2 Testing of Multi-function Protection
2.3.2.1 Type Test

The type test is initiated:
at the end of the design and development cycle of a new product (hardware and software)
at the software upgrade of a function
at the addition of a new function
at the change or marginal upgrade of the hardware
The type test of multi-function protection is first a test of each function (Function Performance Test)
and then a test of the parallel operation of the protection and logic functions (Scheme Performance
Test).
A software upgrade of one function requires type testing of this function and its interface with other
functions. For a numerical relay, the testing consists of tests that are the same for either static or
electromechanical relays and also tests to check the hierarchical structure of the specialised sub-
functions, as shown in Figure 5. Only some of the important tests required for multi-function relays
are highlighted here. A list of test procedures is given in section 3.
12/26/2009 CIGRE 34.10

33
Functional Performance Tests
Check of the settings and setting ranges via HMI

Check each function according to the specifications
Check of correct functioning of disturbance recording (as a special function)
Check of the HMI (as a special function)
Check of the function of logic blocks (programmable logic), individually and in combination
Level of processor load
Correct interfacing to:
other functions
analogue I/O channels
binary I/O channels (masking, marshalling)
Scheme Performance Tests
The influence of processor load can be checked relatively simply by loading the processor from
minimum to maximum with the addition of functions. If there is no in-built function to verify the CPU
load, the timing and the accuracy of the remaining CPU capacity will be checked.
The parallel operation of other functions is not possible to test in all theoretical combinations. One
method is to test one function while other functions are loaded and active and connected to different
I/O channels. Also the reading of the event records provides significant information on the operation
of multiple functions. During the relatively long type testing procedure, the combination of loaded
functions should be changed as often as possible and, ultimately, must include all functions. Fault
conditions and settings need to be selected in such a way that as many functions as possible will
operate.
This list does not contain the Conformance Tests for each function, for the hardware, the operating
system (including event recording), the hardware and software of communication and their interfaces,
and the self-supervision.
Upgrade Type Test
An upgrade of functions, or the addition of new functions, leads to the same test procedure as shown
above, with the exception of testing logical blocks if the programmable logic was not changed. Testing
of the HMI and the disturbance recording function may also be reduced.
2.3.2.2 Individual Tests

Commissioning Tests
The commissioning test shall prove the correct installation and operation of the protection in service.
Related only to the functions of multi-function relays, the tests need to indicate the operation of the
12/26/2009 CIGRE 34.10

34
functions with their settings and the correct internal and external interfacing as employed in the
specific application. The extent of testing depends on the reason for the commissioning test. If the
protection is "adaptive", tests should be made which show the correct performance of the relay when
operating under dynamic conditions. The test plan may be worked out between the manufacturer and
the user.
In addition to the normal conditions, commissioning tests will be necessary when functions are
activated or deactivated from the library.
The important test procedures for multi-functions are:

Dynamic accuracy of the used or new functions (one operating point). The selection of
functions and faults should include the activation of all analogue channels and all wired input,
signalling and tripping channels. This can be reduced if the protection allows measurement of all
input quantities at rated conditions, preferably with internally calculated variables used by the
functions, and the activation of output channels of in-built test functions.
Checking of functions with a set of special fault conditions that are anticipated in this
application (scheme performance). This should also be used to check the correct interfacing with
other functions, signalling, event recording, disturbance recording and communication to the station
monitoring and control system.
2.3.2.3 Periodic Tests

The multi-functionality of a relay influences the method of periodically testing numerical relays.
During periodic testing, the protective device is seen as a black box, to which analogue and digital
input quantities are given, and from which the reaction is evaluated through the output relays.
Considering the multi-functionality of the relay and the limited number of outputs, functional
responses are often grouped through the same output, e.g. a trip output could be activated by a distance
function as well as by internal overcurrent protection. This implies that it will not always be easy to
evaluate which function generated the output.
Several solutions could exist to solve this problem:

Put certain functions out of service. It is not an advisable practice to change the setting of a relay
during periodic testing because the risk of reintroducing wrong settings cannot be neglected.
However, this could be accepted under certain conditions, e.g. if test settings are selected through
parameter set switching that is activated by an input (to be given by the test case).
Evaluate the function behaviour via additional inputs, e.g. start distance, start
overcurent. This implies that many logical inputs are necessary on the test case and that all these
inputs should be evaluated. Thus the evaluation could become quite complex and time consuming.
Only evaluate the scheme behaviour. In this case, there is no concern about the functional
behaviour, but only about the overall scheme behaviour.
The last solution is an acceptable one for digital multi-function protection, considering that:
verifying the characteristics of each function is not useful because there is no drift expected in the
algorithmic part (see also 2.1.2). There may be some drift at the input stage, but this should
12/26/2009 CIGRE 34.10

35
influence all functions that use the analogue signal in the same way and can therefore be detected
through a scheme test.
The self-supervision capabilities of digital relays alter the importance of a periodic test from box
verification for maintenance to environment verification. Indeed, if tests are still necessary (see
also section 2.4 on self-checking features), they should mainly cover the unsupervised parts: input
and output circuits and setting conformance.
The goal of the multi-functionality of the relay is not an increase in the conceptual dependability
(hardware redundancy) but an improvement in the functional dependability (higher sensitivity, less
common mode weaknesses, etc.). Indeed, one processor often performs the different functions.
This improved functional dependability can easily be tested by scheme testing as it is only the result
that matters: was there a trip or not? Whether this trip is generated by the impedance function or by
the sensitive earth protection is of secondary importance.
To summarise, the basic characteristics of the periodic test programme are a functional one, based upon
the scheme parameters. This means that:
injection values are based upon network parameters and not upon settings. This is the best way to
verify that the settings are correct.
meaningful fault conditions are applied instead of searching for boundaries of characteristics.
injection values will be determined in such a way that the boundaries of functionality that are
desired, through the multi-functionality, are reasonably tested.
the evaluation is mainly based on the intended scheme response, i.e. the protection plan.
12/26/2009 CIGRE 34.10

36

ON/OFF state for functions Possibility to test 1 function Function Performance Tests
Function specific logic event Identification of the function Scheme Performance Test
annunciation behaviour during scheme testing Commissioning Test
(all functions in service) Periodic Tests
Function specific identification Ability to accept a function (see Function Performance Tests
(version) also upgrade test) Upgrade Tests

Test Equipment
Synthetic modelling (simulator) Being able to perform a scheme test Performance Tests
approach Commissioning Tests
Periodic Tests
Automatic testing Performing many tests to limit the Scheme Performance Tests
probability of undetected errors Periodic Tests (if necessary)
(Statistical approach)
Real-time transient testing Creating an exact view of all the Performance Tests
interactions between the different functions
during real dynamics.
Test case with multiple logic I/O Number of involved digital I/Os increases Commissioning Tests
with the degree of multi-functionality. Periodic Tests
12/26/2009 CIGRE 34.10

37
2.4 Self-checking Features
2.4.1 Introduction
Modern digital protection relays are provided with several monitoring and self-check functions to
avoid and control internal failures occurring inside the relays. It is commonly believed that these
functions introduce new possibilities for the maintenance of a relay. These possibilities include that
the number of maintenance visits can be reduced and the maintenance interval can be extended. It is
assumed that the self-check functions are so effective that the relay reliability increases and the
maintenance of a digital relay can be restricted to those parts that are not provided with these functions.
This section describes the effect of the different measures to be taken on the reliability of the protection
relay. Also discussed is how the maintenance intervals may be lengthened by the self-monitoring
functions in the protection relay. An overview is given of the various functions that can be defined in
the protection relay. The effectiveness of self-checks can be determined by applying a reliability
parameter to each defined function by which a Monte Carlo simulation model for the protection relay
is realised. In other words, the possibilities to achieve a functional control by a self-check, redundancy
and/or monitoring are determined for each function without taking the protection relay out of
operation.
The reduction in the number of maintenance visits and in the duration of a maintenance visit results in
lower maintenance costs. Based on the effectiveness of self-monitoring functions, a new maintenance
interval may be determined. Different approaches are developed in section 4, Appendix.
In section 2.4.3, the effectiveness of monitoring and self-check functions is discussed. An important
parameter is the effectiveness of self-check functions of the various functional blocks. Figure A2,
curve 2 and curve 4 in the Appendix, shows relays with periodic test and self-supervision. The angle
of the curves and the remaining value after a self-check depend on the effectiveness of the self-
supervision (sometimes called depth of self-supervision). The values of the effectiveness of self-
supervision are not easily available from manufacturers, because this information is usually
confidential.
In section 2.4.4, the reliability of self-supervision is discussed. This reliability is a very important
factor when maintenance is based on the self-supervision of the protection. The problem, however, is
that the precise effect of integrated monitoring and self-check functions is not yet known. For this
reason, users are hesitant to implement new maintenance strategies. Knowledge of the precise effect
would certainly increase the trust in the supervision features.
2.4.2 Determining Internal Functions in a Numerical Distance Protection and Applicable

Checks
For a good overview of the hardware and the software in a numerical protection relay, the relay is
divided into different function blocks. With these functions, it is possible to determine the
effectiveness of the protection scheme by attaching reliability parameters to each function block.
12/26/2009 CIGRE 34.10

38
These function blocks can also be used to indicate whether a certain part can, or cannot be, controlled
by self-checks. In this way, it is possible to indicate the necessity for periodic maintenance on
particular parts and detail how this maintenance can be performed for each function.
In Figure 6, a schematic diagram of a numerical protection scheme is shown, with both hardware and
software functions indicated. The diagram shown is a typical configuration. Commercially available
relay information may be used to determine the different functions in more detailed blocks (e.g. input
transformers or sensors, sample & hold, etc.). Manufacturer differences occur in bus-systems, number
of processors, etc. The grey blocks are functions outside the protection relay and determine the
protection scheme.
Clock Power Supply Unit
Analogue Measuring System Analogue and Digital ROM Software

CT/VT Input Conversions Process
Interconnection Internal CT/VT System
Digital input Bus Aliasing filter software
Data acquisition RAM Protection
functions
Logic Input System Interface
Activators software
Logic In EEPROM Self
(relays,comm.)
Opto-couplers
Interconnection monitoring
Processors
Logic Output System Processor 1
Responders (breaker!) Logic Out
Processor 2
Relays
Interconnection ..
Processor n
Watchdog
Communication
Alarm Generation System Comm. 1
Interconnection Comm. 2
Self-supervision Alarm
Generator Relay ..
Comm. m
External Bus System Internal Bus
Figure 6: Schematic Diagram of a Typical Numerical Protection System
Self-checks, redundancy and monitoring are applied to detect and/or to avoid faults in the described
functional blocks. Possible self-checks for each described function in a numerical protection relay are
described and listed in Table 3 for the external functional blocks and in Table 4 for the internal
functional blocks. Moreover, if no self-check exists, the possible test column describes how the
block can be verified through intervention. Of course, the necessity for external tests is not only
determined by the existence or lack of self-supervision, but also by the effectiveness of the supervision
(see 2.4.3).
12/26/2009 CIGRE 34.10

39
Functional Example of Applicable Estimated Test Possible Tests

Blocks Self-check Effectiveness
Analogue Plausibility checks Read-out of actual
measuring system V = 0, I = 0 measurements
V = 0, I = 0 (with
symmetry factor)
V0 AND NOT I0
V2 AND NOT I2
Bi-directional
communication
Process bus (future)
with intelligent
protocols
Redundancy
Double input
conversion
Logic input Intelligent communication Read-out and verify actual
system Test pattern states
Intelligent protocol Generate input conditions
Bi-directional through the Logic input system
Redundancy +redundancy
check
Double input signals
Logic Output Bi-directional Activate outputs and verify
system communication response
intelligent protocol
response return (e.g.
breaker position)
External bus Intelligent protocols Communicate through bus
system Test patterns
Redundancy checks
Alarm generation Bi-directional Generate alarm and check
system communication receipt at dispatch
intelligent protocol
alarm receive
Inverse logic (send healthy
state)
Table 3: Supervision of External Functional Blocks
The supervision of these external blocks is generally not independent of the internal blocks with which
they are linked. Indeed, the supervision is internal in the protection and most supervision criteria
verify the whole chain (certainly for input information). Some of the supervision criteria can therefore
also be found in Table 4. However, it is important to make this distinction in order to highlight the
scheme approach. As an example, for the protection check, it is sufficient to verify that the supervision
alarm is raised by the output of the relay, for the scheme check this alarm must be received at the
operation centre.
12/26/2009 CIGRE 34.10

40

Analogue and Plausibility checks read-out of actual measurements
digital input V = 0, I = 0 read-out of recent fault records
conversions V = 0, I = 0 (with present test signals (test set)
symmetry factor)
V0 AND NOT I0
V2 AND NOTI2
Redundancy checks
V = VE, I = IE
double input
conversion
Internal signal generation
Present test pattern
logic in Redundancy checks read-out and verify actual states
double input Generate logical input conditions
conversion (test set or through system)
Internal signal generation
present test signal
(reference voltage)
bi-directional
communication
Intelligent communication
logic out Redundancy checks verify and evaluate actual states
redundant control activate outputs and verify
circuits with response (at outputs or through
comparators system)
Intelligent communication
bi-directional (verify
action)
ROM Redundancy + redundancy read-out and verify actual
checks measurements
signature read out and verify masking or
cyclic redundancy marshalling and settings
check(CRC) or other
checksums
RAM Test patterns read-out of actual measurements
walkpath
checkerboard
(e.g. March)
galpath
EEPROM Redundancy + redundancy read-out and verify settings
checks
checksum (exclusive
OR principle) e.g.
cyclic redundancy
check CRC 16
extra control bits to
data word
12/26/2009 CIGRE 34.10

41

processors(s) Redundancy + redundancy read-out of actual measurements
checks read out of settings
software in two present tests and verify
memories behaviour
watchdog (monoflop)
Software process Algorithmic checks read-out and verify actual
result compatibility process results
redundancies present tests signals and verify
Execution checks response (test set)
timers
process check
Communication(s) Redundancy + redundancy read-out and verify transmitted
checks values
extra control bits to
message
protocol (checksum)
time out
Power supply unit Supervisions read out PSU voltages
voltage levels and present test voltages
range
quality survey
Active logic
alarm needs power
supply
Internal bus present test pattern for read-out and verify
RAM measurements and settings
handshake protocol present test signals
Watchdog and Redundancy + redundancy create alarm conditions and
self-supervising checks verify response at output
alarm redundant control
circuits with
comparators
separate bus
Present test signal
Clock read-out and verify
measurements
Table 4: Supervision of Internal Functional Blocks
2.4.3 Effectiveness of Monitoring and Self-check Functions

The amount of planned maintenance depends upon the effectiveness of the monitoring and self-check
functions and of the number of these functions per functional block. In theory, maintenance is not
required when the self-checks listed with each functional block are implemented. It must be realised,
however, that the reliability of the self-check for each functional block must be higher than the
reliability of the digital protection relay itself. Another aspect to remember is the depth of the applied
self-checks. An example is the different self-checks that may be used to check the ROM within the
12/26/2009 CIGRE 34.10

42
digital protection relay. Using a checksum, 50% of the faults within the ROM are detected, whereas
99.6% of the faults are detected when using a signature.
In general, a manufacturer only specifies if a self-check is applied or not for a functional block. For a
good understanding of the effectiveness of a self-check, and the implication on the maintenance
strategy, it must be known what percentage of the faults is detected. In order to assess the
effectiveness of supervision features, this information has to be provided by the relay manufacturer. It
is generally not possible to dispense with periodic tests because a large portion of protection relay
faults are not detected by the self-monitoring function. In Tables 3 and 4, a column is given for
information about the effectiveness of the self-supervision for each functional block.
With this information, a simulation programme can be used with a random fault generator to test the
functional blocks. The results would provide a good indication of the effectiveness of the self-
supervision of the protection. However, the goal here is mainly to evaluate the results for periodic
testing. Therefore, the determination of the effectiveness of each functional block is sufficient since
the results are detailed for each block.
Normally, the percentage of effectiveness should be given by the manufacturer. Except for some
specific cases, it is not feasible to determine the effectiveness of the self-supervision by testing
because:
Destructive manipulations are often involved when testing hardware supervision
The software source code is not available to test labs or users, thus code errors cannot be generated
to test software supervision
Interruption of messages by manipulation of connections may cause serious damage
Some simple tests can however be performed to verify that the supervision alarm is raised, such as:
remove supply voltage
remove analogue neutral input and leave all other phases intact
remove an I/O card (if possible)
remove an EEPROM or interrupt loading flashed EEPROM
A more extended list is provided in section 3 (see 3.2.4). Fortunately, testing effectiveness is most
feasible for the external blocks. These are indeed the most difficult parts to supervise internally.
2.4.4 Reliability of Self-supervision

In theory, the implemented monitoring and self-check functions can also fail. In this case, there is a
possibility that a fault in a certain functional block is not detected by its self-supervision. Because the
relay user is not warned when a fault in the self-supervision occurs, this is a very undesirable situation.
The user assumes that the relay is still working properly and is not aware of a dangerous situation.
In order to prevent this situation, it would be desirable that an alarm signal be given after the
occurrence of a fault in a self-supervision feature. Until now, such an alarm signal has not been
implemented in digital relays. Such a feature would, however, certainly increase the trust in the self-
supervision features and decrease the barrier to switch to a new maintenance strategy. To stress the
importance of such a feature, it is included in Figure 6.
12/26/2009 CIGRE 34.10

43
2.4.5 Contents and Interval of the Maintenance Work

A maintenance philosophy for numerical relays will take into account the effect of monitoring and self-
check functions on the reliability of a relay. Presently however, it is not quite clear what the contents
of the maintenance work will be and what will be the optimal maintenance interval. Different
approaches are given in the Appendix. Investigation by German manufacturers has shown that the
areas not covered by self-monitoring are essentially the same for all manufacturers: analogue input
measuring circuit up to the A/D conversion, and the binary inputs and outputs (indication and
command circuits).
Concerning the content of the maintenance, it is clear that maintenance is at least required for
functional blocks that are not provided with self-supervision features and where the depth of the self-
supervision features are not adequate. Furthermore, it is advisable to make full use of on-line
maintenance." This is because the availability of a numerical protection relay is reduced during
maintenance when the relay is taken out of service. The communication features of numerical
protection relays allow remote reading of relay settings and actual measurements during the time that
the relay is in service. For the reading of actual measurements, for example, the communication
processor, processor, ROM, RAM, parallel bus, serial bus and HMI are used. The functionality of
these functional blocks can be checked at this time. Satisfactory results of the measurements read can
demonstrate that the A/D-conversion function is operating correctly. The functionality of the inputs
can be checked in the same way. An overview of the possible checks on the functional blocks that can
be controlled during the time that the relay is in service is shown in Table 3 and Table 4.
Moreover, the existence of internal fault recording and/or fault monitoring permits analysis of the
protection behaviour during a real fault, e.g. during back-up functioning. Comparing the measured
current with other measurements during faults is a means of verifying the high stage of the analogue
current inputs.
It is expected that, in the near future, self-supervision features will generate recommendations for
repair after an error is detected inside a functional block. This information will certainly be useful in
developing a new maintenance strategy. Depending on the information of the protection relay
provided by the manufacturer, additional points might require observation such as the replacement of
batteries and/or capacitors after a certain number of service years.
Of course, there is often a parallel protection available when a protection is taken out of service and,
often the maintenance of protection and control equipment is performed in parallel with HV
maintenance. During HV maintenance, tests can be performed that are not possible when the
protection is in service, e.g. to check the high-stage of amplifiers and saturation effects. Further, it
should be noted that there is hesitation in performing tests remotely, because of undesirable affects on
the operation.
12/26/2009 CIGRE 34.10

44

Requirement Reason Type of Test
Division of self-supervision Information is needed to assess the Technological Conformance Tests
features among functional blocks effect of the different features on
the relay behaviour
Reaction of self-supervision Information is needed to assess the Technological Conformance Tests
features on internal failures effect of the different features on
the relay behaviour
Test depth of various self- Information is necessary to assess Technological Conformance Tests
supervision features the effect of the different features Function Performance Tests
on the relay behaviour
Test interval of different self- Information is necessary to assess Technological Conformance Tests
supervision features the effect of the different features Function Performance Tests
on the relay behaviour

Demands on the Reasons Type of Test
Test Equipment
Theoretical evaluation using Determination of the effect of self- Technological Conformance Tests
functional model of a protection supervision features on reliability
and subsequent determination of
optimal maintenance interval
Reliability assessment Check of the measures taken by the Technological Conformance Tests
manufacturer by quantitative- or
qualitative methods of assessment
Remote testing of functions Possibility of new maintenance Periodic Tests
approach
12/26/2009 CIGRE 34.10

45
2.5 Digital Communication Ports and Remote Hardware and Software
2.5.1 Introduction
Numerical protection devices can have different types of communication with their environment:
HMI-keyboard communication to the relay
Personal Computer communication to the relay
Remote communication from Central Control Centre
Inter-protection communication
Inter-substation communication
Electronic transducers communication to the relay
The HMI keyboard communication is used to configure the relay in its installation. The PC to relay
communication is done through a serial port interface. In local communication, a front serial interface
RS-232 port of 25 or 9 pins is often used. Remote communication is done through a rear serial fibre
optic or EIA multi-point RS485 connection with a copper wire-based transmission via telephone
modem or other communication link.
The inter-protection communication is used to communicate with the relays of the protected circuit
ends, e.g. the different switch bays in a substation for digital bus protection. The inter-substation
communication is used to communicate with several devices within an integrated substation (control,
meter, and protection). The electronic transducer communication (CT and VT) will be used in a
completely integrated substation computer system or in a refitted classical station.
One of the benefits that digital protection relays offer, compared to the conventional electromechanical
and static protection devices, is the possibility of exchanging information with the external world. This
is a useful data exchange that can be used by operators, fault analysis personnel, protection
maintenance personnel, etc. This selected information also reduces the communication traffic between
the substation and the control centre.
Information stored by protection equipment during normal operation, or during and after disturbances,
can be retrieved remotely from the System Control Centre or from the Protection and Fault Analysis
Centre. The following information can be stored:
time-tagged indication of the external and internal state of the protection and self supervision alarms
time-tagged restart of the relay
chronological fault events
time-tagged operated units
settings in service
pre-fault, fault and post - fault voltages and current values
fault records
fault location
12/26/2009 CIGRE 34.10

46
It is also possible to change settings, which permit the use of the adaptive protection features, and
transmits the actual values of voltages and currents remotely. Furthermore, due to the complexity and
the great number of functions integrated into the protection, a PC software programme is essential to
install the settings, using a setting file previously established, and to retrieve the stored oscillography
and events information.
2.5.2 Communication Protocol Testing: Compliance with Standards

One of the aims of electric utilities with respect to digital protection is to accomplish the interchange,
or at least the coexistence, of devices from different manufacturers, in an open communication with
remote software that is compatible with different suppliers. An exhaustive definition of procedures
used is required to simulate the communication protocol. Waiting intervals, number of trials before
giving an error, requested information, and many other factors need to be taken into account.
Despite simulators and procedures, problems of compatibility could appear when two devices from
different suppliers are attempting to communicate. Depending on their software version, slaves may
not send all the requested data because they may not have all the information requested.
There are two types of communication protocols: closed protocol, which normally are manufacturer-
specific standards, and open protocol, which are based upon Open System Interconnection (OSI)
architecture. The closed protocol includes devices from one manufacturer. Therefore, the user is
forced to buy a complete solution from a unique supplier. If devices from a different manufacturer are
connected, expensive protocol emulation must be developed.
The open protocol is based upon international standards. The International Organisation for
Standardisation (ISO) has defined one information processing system, reference model OSI (ISO
7498), that structures the communication functionality into seven layers. There is another protocol
reference model, Enhanced Performance Architecture (EPA), which is a simplified model of the
previously cited seven-layer architecture. This model is used in telecontrol systems and other systems
that require faster response time in networks with a limited transmission bandwith. The IEC 870-5
International standard for data transmission protocols on telecontrol equipment is based on the EPA
reference model. This standard, with the profile 103 companion standard for protection
communication, is used as an open protocol for information exchange between digital protection and
control systems. If different manufacturers implement this open protocol on its equipment, an open
communication between physically connected devices from different manufacturers can be achieved.
It should be mentioned that other standard protocols exist. In the last years studies have been done
on protocols that are derived from the specific IEC 870-5-100 series protocols in a move towards
general protocols. These are in use in industries such as the process industry. These protocols are used
because they have proven their reliability, having been used by manufacturers in many other
applications. This affords an economic advantage. Testing of these kinds of protocols will be far more
complex.
12/26/2009 CIGRE 34.10

47
2.5.2.1 Open Protocol Conformance Test

When an implementation complies with a given standard, one speaks of conformance. Conformance
testing is the way to avoid incompatible implementation of standard protocols. The conformance
assessment of the implementation in one product may be certified based on user requirements.
Master or slave functions are simulated to create a live environment for the System Under Test. The
master or slave is accessed by its interfaces to the next layer. While control patterns are passed at one
interface end, at the opposite interface the reactions are observed and registered. The quality of the
conformance test depends on the quality of the selected test cases and the degree of coverage of the test
protocol specification. It will be noted that consideration of all test cases is not possible, such test
cannot prove that a protocol implementation is error free.
2.5.2.2 Open Protocol Compatibility Test

The compatibility test proves if a protocol that is installed in one device is able to exchange data with
another device from a different manufacturer in which the same protocol is installed. This test shows
the compatibility of several installations, already individually conformance tested, to find
incompatibilities that may be due to either an incorrect communication configuration or to the role
played by the programming language in compatibility. Because programming language testing is not
the object of conformance testing, the compatibility test is aimed at assisting users.
2.5.2.3 Open Protocol Data Information Test

This test is to check the principle behaviour of all distinct information elements and function for
correct processing, operation and presentation. The Data Information Test could contain elements such
as processing of digital and analogue points, presentation on monitor or printer, execution of
commands, activation of certain function by the protocol, e.g. teleprotection, breaker failure protection
and autoreclose functions. Additionally, the Data Information Test contains a number of worst-case
events that could occur after installation, for example:
simultaneous presentation of a command and a fault in the first protection zone
occurrence of a fault on the protected element during a communication transmission process, e.g. an
oscillographic record
occurrence of a fault during HMI communication link
simultaneous presentation of avalanches of events during a setting change process
simultaneous presentation of several digital inputs and a fault in the protected zone
occurrence of a remote communication during the time calculation of an inverse overcurrent unit
The correct processing, operation and presentation of all information elements and functions are
checked on the control panel and/or the printer.
2.5.3 Immunity Testing: Compliance with Existing Standards

Digital communication ports of measuring relays and protection equipment must comply with
International Standards. The difference between older techniques and digital techniques is the
existence of digital ports for various functions:
data communication port
12/26/2009 CIGRE 34.10

48
inter-protection port
HMI
The IEC 255-5 and 6 standards for insulation test and the IEC 255-22- series of standards for
immunity to disturbance tests, are already valid for numerical relays. In any case, not all data
communication ports have the same requirements. For example, the operator terminal interface (local
PC to relay communication) normally is a non-isolated port, and the inter-protection communication
(relay channel communication) is isolated and has the same requirements as the relay itself. The
interface for data transfer to a control centre is also isolated. All these are standard type tests and shall
be carried out in a laboratory.
Because of the peculiarities of different substations and, depending on their age, the switchgear layout
and earthing system can cause problems with the relay response. The retrofit of old electromechanical
relays by modern digital equipment could create some EMC problems during opening and closing
operations of high voltage grid elements, like bus or feeder disconnect switches and circuit breakers.
The coupling mechanism has a special effect on the secondary circuits of instrument transformers and
on their connected protection devices. Another influential factor is the link of these circuits to the
primary elements via the instrument transformer's internal capacitance. The requirements for switching
action are defined in IEC60694.
In some special cases, when installing a new digital protection device with today's standards and
detailed utility's laboratory test in an older substation, it is prudent to perform some field tests. For
example, some operations with high voltage disconnects and with different busbar sections and circuit
branches (breakers, CTs, VTs) in service, opening and closing the switches at different speeds and
checking the influence in the behaviour of the new protection.
2.5.4 Testing Local Communication and Remote Software Quality as Part of the Approval
Procedure
In order to verify that the programme application software meets the manufacturer specifications and
the user requirements, three different cases should be considered.
1. The HMI software is part of the relay. In this case the HMI is undoubtedly linked with the
protection and should be type tested each time as a function of the protection.
2. The local communication software is standard, but addresses protection-specific files. In this case
the local communication software might be type tested independently for its general characteristics
(user friendly and abilities), but correct interfacing and response should be verified with each type
tested protection.
3. The remote communication is standard for a complete range of protection. This case is similar to
the case seen in section 2.5.2 Communication Protocol System. In this last case, a compliance
test of the software version of the relay, as well as the software version of the remote
communication protocol might be performed.
Once the configuration of the protection and PC (local or remote) are matched, some confirmation of
the performance of the communications and the quality of the software should be carried out:
AC current and voltage value test
programmable Input and Output test
12/26/2009 CIGRE 34.10

49
disturbance recorder transmission test

COMTRADE format compatibility test (standard ANSI/IEEE C37.111 or IEC 255-24)
event recorder list transmission tests
writing and reading of relay settings test
different users access levels
open and close command test
Some of these points will be verified through the normal test programme of the protection.
2.5.5 Communication Port Testing: Compliance with Standards

Interfaces are the connections between two or more devices that transmit data and control signals. In
every interface, all physical properties of the signal are exchanged and their meanings are determined.
In general, interfaces implemented in digital protection equipment are serial interfaces that transmit the
bits of a character in a string through the medium.

Some minimum requirements are given in the table, below, and only concern testing requirements.
Using internationally accepted Compatibility with other local or All tests
communication standards with remote devices
open protocols
Giving a clear description of the Consistency of the version All tests
used protocol between the relay and the
application software
Providing several communication - Establishing different types of All tests
interface ports communication
- Verification during testing
12/26/2009 CIGRE 34.10

50

Some demands on the test equipment, created by digital communication ports, are given below. Every
specific type of digital communication port is not necessarily creating all the demands. These demands
can, however, be considered as a general tendency.

Test Equipment
Protocol tester Protocol Conformance Test: Compliance to Technological
standards or specification Conformance Tests
Reference equipment or Protocol Compatibility tests: Communication Functional Conformance
tester between products of different manufacturers Tests
Reference data set and reference Data Conformance Test: Compliance to Functional Conformance
programme standards or specification Tests
Communication simulation Check the communication path (phase, Functional Conformance
equipment jumps, jitter, delay, rerouting, etc.) Tests
3-phase test sets capable of Simulate system conditions (3-ph). Type Tests -
reproducing COMTRADE files Commissioning Test
with all transient components Periodic Test
GPS receivers Satellite synchronised end-to-end scheme Commissioning Test
testing. Inter-protection communication Maintenance Test
evaluation
12/26/2009 CIGRE 34.10

51
2.6 Adaptive Protection
2.6.1 Introduction
The problem of testing adaptive protection is addressed in the report of the working group 34.02 on
adaptive protection and control [Ref 16]. This chapter is partially based on Chapter 8 of that report.
The WG34-02 report gives the following definition concerning adaptive protection:
Adaptive protection is a protection philosophy which permits and seeks to

make adjustments in various protection functions automatically in order to
make them more attuned to prevailing power system conditions.
Some examples are:

parameters set to adapt a function to specific network conditions, e.g. the opening of a parallel line
using the earth current signal of a parallel line for mutual compensation
load compensation
tap-changer position controlled differential transformer protection
synchronised phasor measurement for out-of-step protection
Adaptability is not new. Some form of adaptability exists in older techniques. There is, however, an
evolution in the kinds of adaptive functions and the way of achieving it. This evolution, based on
digital techniques, has some consequences on both testing philosophy and testing equipment.
Analysing the above definition in detail, some important points related to protection testing appear:
..Make adjustments in various protection functions..: Generally, there is an integration of
different functions, including the adaptive function itself. This subject is handled in section 2.6.2:
Integration of the Adaptive Function.
..Automatically..: The adaptive state is conditioned internally or externally by logic or analogue
information. The consequences are discussed in section 2.6.3: Conditioning the Adaptive
Feature.
..In order to make them more attuned..: The non-adapted mode is not a failure mode nor an
incorrect mode. Thus, it cannot be evaluated by self-supervision. The discussion of this item is
given in section 2.6.4: Correct Adaptation.
..To prevailing power system conditions..: There is a tendency toward system-wide approaches.
More detail can be found in section 2.6.5: System Controlled Adaptation.
The minimum requirements on the relays themselves and the special demands on the test or evaluation
equipment are handled in sections 2.6.6 and 2.6.7.
2.6.2 Integration of the Adaptive Function

The consequences of integrating the adaptive function are mainly covered by section 2.3 on multi-
function protection. Some points are highlighted here:
12/26/2009 CIGRE 34.10
52
In most cases, the adaptive function is controlled by an external logic or analogue signal. For
certain tests, this signal should be simulated, thus an additional digital or analogue input must be
available on the test equipment. The analogue signal could be a current or a voltage. If
commissioning or maintenance tests should be performed on the adaptive feature, portable test
cases should provide these inputs.
The integration of functions makes it generally difficult to inject signals between functions.
Signals can only be injected at the hardware borders, not at software (module) borders. By taking
functions out of service or by reprogramming input/output, it is sometimes possible to isolate
certain functions and to make the software borders correspond to the hardware borders. Also,
information (I/O-states, measured values, etc.) can be available at the software borders. This
information can help to properly analyse the behaviour of the function. As with multi-function
relays, the main problem is that the number of conditional combinations will rapidly increase with
the number of adaptive possibilities. Another testing approach will be necessary.
It is also possible that there is no clear border between the adaptive system and the normal
protective system. The adaptive effect cannot be isolated in that case. This will generally be the
case with auto-adaptive features requiring no additional input (example: load compensation) and
for protection using Artificial Intelligence techniques such as Fuzzy logic, Neural networks and
Expert systems.
Changing the settings or the parameters of a protection in order to efficiently test a relay with many
internal functions is a controversial philosophy for commissioning and maintenance tests. Some
people accept this to keep the test procedure simple. However, others do not, since the probability of
finding a problem is lower than the risk of creating one. One feature that can help to overcome the
problem is to have different setting groups. In this way, a separate setting state can be activated for
testing.
2.6.3 Conditioning the Adaptive Feature

For this section, reference is also made to the sections on Programmable I/O Logic (2.2) and on Digital
Communication Ports (2.5). The way the information is presented (digital communication bus, optical
input, etc.) is not discussed here.
The problem is to assure that the true power system state correctly activates the adaptive state. This is
a matter of connections and wiring. Verification of this can range from a very simple task to a very
onerous effort. Verifying the correct transfer of a local logical state (example: breaker position) is
relatively simple. Verifying the correct introduction of an zero sequence current (example: mutual
compensation with the I0 of a parallel line) is more difficult because of the uncertainty of the direction
of the current. An I0 current cannot be verified with normal load and eventually requires primary
injection. Verifying the correct transfer of remote information can also be onerous. This is especially
true when time synchronisation has some importance. If a time delay should be measured precisely
between two distant locations, special measuring devices or synchronising systems like GPS will be
necessary.
Conditioning the adaptive feature generally requires external information and, since the outside world
cannot easily be supervised (except via redundancy), these verifications will be the last surviving in
12/26/2009 CIGRE 34.10

53
maintenance tests. It is important to keep them under control. If the periodic verification of the
adaptive feature costs more than the benefit gained, it might be better to live without the adaptation.
2.6.4 Correct Adaptation

It is stated in the definition of adaptive protection that the adaptive function tries to attune the relay.
This means that the non-adaptive function is also an acceptable, although functionally degraded, state.
Consequently, no supervision alarm can be raised in functions of the active state. Internally, all states
are equally acceptable.
The non-adapted state is not an incorrect state; it is only less adapted. It will not necessarily create a
false behaviour (unwanted trip, no-trip). Only in certain specific, and eventually rare, conditions, the
behaviour will be faulty. Creating this condition during commissioning could be very difficult.
Therefore, the evaluation should be based on more information than the trip/no trip condition.
Internal state or measuring information is often indispensable. It can be expected that in most
functions, the effect on the measuring result will be perceptible in a broader area than the effect on the
trip decision. Basing the evaluation on the measurement means, however, that how the measurement is
influenced by the condition must be known. For simple functions this can be verified by calculation,
for complex functions, a parallel simulation programme might be necessary. In any case,
manufacturers advise is necessary.
Example: inverting the connection of the I/O current for mutual compensation will not necessarily
create a false trip for a fault at 100% of line length, but it will certainly influence the distance
calculation.
2.6.5 System Controlled Adaptation

The need to adapt the protection to prevailing power system conditions - see definition - and the fast
increase in communication possibilities creates a tendency towards system-wide philosophies (example
stability evaluation through phasor comparison). This creates new needs in protection testing:
Adapting to the system: The system is generally 3-phase. Until now, individual tests could be
performed with a 3-phase voltage/1-phase current test set. For example, taking into account the
system load flow requires 3-phase current simulations.
System-wide testing: It is common practice to reduce the network during type testing to the
minimum necessary to verify the behaviour (see WG 34-06 report: double source - double line
simulations for line protections). If the adaptive feature is conditioned by a wider view of the
network, it will be necessary to extend the simulated network.
Prevailing system conditions: Until now, the protection was influenced by the dynamic fault state
and, eventually, a short pre-fault window, i.e. a dynamic window of hundreds of milliseconds.
Adapting to prevailing system conditions can create an appeal to changes of time constants to
seconds or even minutes. Non real-time simulators will have difficulty to achieve the simulation
time demands unless they work with variable sample frequency. Real-time simulators will become
essential for successfully testing these adaptive features.
12/26/2009 CIGRE 34.10

54

Some minimum requirements are given below and only concern requirements related to testing. This
analysis does not address the other requirements for correct implementation of an adaptive feature.

Placing functions IN/OUT of - Isolating the adaptive function Type Tests
service - limiting test amount Acceptance Tests
Programmable I/O logic Isolating functions Type Tests
Acceptance Tests
Commissioning Tests
Having a clear indication on the - Evaluating the behaviour Type Tests
current active adaptive state or - Verification during service Commissioning Tests
some measuring results Periodic Tests
Having different setting/ Adapt settings during testing Commissioning Tests
parameter groups Periodic Tests

Some demands on the test equipment created by adaptive features are given below. Every specific type
of adaptive feature is not necessarily creating all the demands. These demands can, however, be
considered as a general tendency.

Test Equipment
3-phase testing systems Simulate the system conditions (3-phase) Type Tests -
Individual Tests
Increased number of logic and/or Activation of adaptive condition All types of tests
analogue outputs
Simulation of the adaptive signals Functional verification of adaptive features Type Tests -
Commissioning Tests
Wide network simulations System wide adaptations Application Type Tests
Real-time simulators Simulation of system conditions Type Tests
requiring long simulation windows
Functional protection simulators Evaluating the behaviour function of All tests
internal measurements
GPS receivers Synchronised measurements between Commissioning Tests
distant locations Periodic Tests
12/26/2009 CIGRE 34.10

55
2.7 Software Evolution Independent of Hardware
2.7.1 Introduction
The concept of digital protection allows a clear distinction between the functional" and the material
parts. The border between the two is almost the same as the border between software and
hardware:
the material part is the hardware of the protection
the functional part is the software of the protection
The system programme runs between them, which is in fact software but much more linked to the
material part. Indeed, the system software is closely related to the processor(s) and the real-time
process handling. The system software (operating system) largely determines how independent the
software is from the hardware.
Disconnecting the functional part from the material part is very interesting because it allows functional
enhancements without having to develop another protection. New or changed software is introduced in
a physically existing relay, where relay stands for the hardware.
One important question should be raised: Should the evolved protection be considered as a new relay?
From a testing perspective, the question becomes: Should testing be performed on upgraded protection
and, if so, what kinds of tests should be performed? A straightforward answer cannot be given except
that there would probably be general agreement that some sort of tests should be performed. But the
necessary amount and depth of testing depends on various factors:
What is the type of modification? Does it concern a correction, an improvement, or the addition of a
function? Or is the system software itself changing?
Is it an important modification? Is the fundamental function of the relay involved or only a
supplementary, and non-used, or background function? Note that this analysis is user dependent as
a function can be supplementary for one customer and fundamental for the other.
What is the policy of the user concerning testing protection? Does the user rely completely on the
manufacturer or is self-verification important? Does the user accept every upgrade or is there a
desire to limit the number of upgrades? What effort is willing to be invested in verifying upgrades?
These factors will determine the test programme. They are subjective and user-dependent, which make
it difficult to determine a specific testing programme. Nevertheless, we can again develop some
generic ideas.
The analysis is divided into 3 separate parts that will be discussed hereafter:
1. Demands on software quality
2. Type testing a software upgrade
3. Individual testing of software upgrades
12/26/2009 CIGRE 34.10

56
2.7.2 Demands on Software quality

It is clear that the quality of the global structure (system software) and the software functions is the
main factor for a reliable product. The following basic development rules are generally recognised as
important for achieving high quality software in digital protection:
Use of a high level language
Top-down approach
Clearly defined modules with well-defined interfaces
Clearly visible signal flow and timing relationship
Clear and structured design
Structured programming
Incorporated evaluation points in the software
Module version identification
Compliance with Quality Insurance Standards (ISO-9000-3 for software), which includes some of
the previous requirements.
Verification by the user or by a certifying organism as to whether a certain relay is developed

following these guidelines is not a pure test activity. However, it is interesting to evaluate this
information as a means to determine to what extent upgrade problems might be expected. It should be
noted that manufacturers generally accept these development rules as they are for the users benefit as
well as for the manufacturers one. But it should be noted that these rules do not assure functional
ability, they are only prerequisites.
Functional ability can be verified by evaluating the manufacturers acceptance process. This process
can be divided into three levels:
1. Accepting the software function
2. Accepting the software in the hardware
3. Accepting the system
The system acceptance is in fact a type testing of the relay (see 2.7.3), although in a more simplified
form (see 3.5). Some guarantee can be given with a certificate from an independent certifying
organisation.
The operation of the protection can be observed over a period of time using beta-release software, with
or without connecting the trip output to the breaker. Beta releases (pre-release software for field
testing) is common in the computer world as a means to debug the software. In the relay protection
world, to readily use beta release software would degrade the reliability of the system protection and,
therefore, this practice is not normally accepted. Although system protection personnel prefer to wait
for a mature product, in practice the first users unintentionally play the role of software debugger.
Moreover, due to the limited population, it would take too long to effectively debug a relay software
through observation.
12/26/2009 CIGRE 34.10

57
It should be noted that the verification of every item above is not necessary in all cases. The need is
more related to the type of change (correcting, improving, adding, etc.). For example, if an internal
AND is simply changed to an OR, the processor load and interface remain the same. Therefore
hardware tests are not really necessary. Common sense can be applied when verifying the proper
operation of a software upgrade.
2.7.3 Type Testing a Software Upgrade

Type testing an upgraded version of a protection could be completely the same as type testing a new
protection, but it is prudent to limit the number of tests in order to remain cost-effective. This section
will focus on the minimum programme. Therefore, the effort will be limited to the following three
items:
1. Verifying that the new (or changed) function works correctly. Therefore it is necessary to activate
the part of the function that is new (or changed) and see if the system responds as expected.
2. Verifying that no other functions are deteriorated. This is much more complicated as it requires
testing all combination possibilities of the new (or changed) function. Again, probability testing
will be needed here. Representative samples should be defined in order to limit the number of
tests.
3. For users: verifying that the new version remains compatible with the scheme used.
The manufacturer acceptance of a software focuses more on verification that the changed parts work
correctly instead of on verification related to deterioration of other functions. Therefore, the main
interest of user-defined type tests lies in general tests using the applied configuration. Some users will
prefer to do more, but as each combined use of functions is typical for a certain user, and can even be
unique, the probability of detecting problems becomes higher. By performing some tests in a typical
configuration, the user is assured to a certain degree, that there will be no problems with his use of the
relay.
It is important to note that incompatibility with a user's typical application will never be classified as an
error by manufacturers, nor by a certification organisation. Changing the definition of function or
issuing information might be justified technically, but it doesnt mean that it causes no problems in the
users application. This is the main interest of users' upgrade tests.
The easiest type test of upgrade performance is to be able to compare the results with earlier tests.
Therefore, tests should be standardised and the data saved. Replaying exactly the same test should
provide (almost) exactly the same results. If not, differences should be investigated. Are they
intentional or unintentional? If they are wanted, they should be indicated in the change list.
Some related protection type issues should be verified also:

Is the read-out software of the relay compatible with the version?
Is the version compatible with pre-defined (automatic) commissioning or periodic test routines?
These verifications are generally easy to do (not the correction) and can avoid unpleasant situations
during commissioning.
12/26/2009 CIGRE 34.10

58
2.7.4 Individual Tests on a Software Upgrade

Acceptance tests on an upgraded version of a protection remain nearly the same as on the original
version. Eventually, the qualification programme should be adapted to the changes or should integrate
a test on a new function. An important verification, however, is the verification of version
compatibility:
Does the version correspond to the one that was ordered?
Is the module version compatible with the hardware and the rest of the software?
If the software upgrade is delivered in a specific hardware, it is mainly the responsibility of the
manufacturer to assure the internal compatibility, but the external upgrade is often the responsibility of
the user. If the software is delivered as a module and the implementation is left to the user, the user
will need to perform the verification.
If a field upgrade to the existing protection is needed (correction of an error), the relay should be
recommissioned. Important matters related to field upgrades are:
Verification of the version compatibility
Verification of proper implementation. The manufacturer should describe some tests to verify the
proper implementation.
Verifying the influence on input/output parameters and setting parameters. Has the relay lost all its
data or is it still available and correct? For example, if an upgrade of a function includes an
additional setting parameter, it should be verified that all other parameters are shifted correctly. It
is advisable to compare the new parameter list with the old one.
If a change occurred to the input/output parameters, it is necessary to redo all commissioning tests.
12/26/2009 CIGRE 34.10

59

Some minimum requirements are given hereafter and only concern requirements related to testing.
Requirements Reasons Type of Test

Placing functions IN/OUT of - Isolating the changed function Type Tests
service - limiting test amount Acceptance Tests
Programmable I/O logic Isolating functions Type Tests
Acceptance Tests
Commissioning Tests
Being informed about the changes - Determining necessary tests Type Tests
in the new version - Adapting the environment Commissioning Tests
Having manufacturers procedures Confirm proper implementation Individual Tests
for successful implementation of
new software.
Having adapted HMI-software Use of protection All Tests
Testing the HMI Type Tests
Having a comparison test Evaluating new performance Type Tests

Test Equipment
Extra logic/analogue outputs Creating specific conditions All tests
Functional protection simulators Testing the protection close to system Type Tests
power conditions
Automatic library testing Comparing new version with older ones Type Tests
12/26/2009 CIGRE 34.10

60
3. Guidelines for Testing Numerical Protection
In this chapter the goal is to give a generic description of the tests to be done for each test category
given in Table 1. This chapter should be of practical use as a reference for the test engineer.
Justification of the developed philosophy is given in chapter 2.
12/26/2009 CIGRE 34.10

61
3.1 Functional Conformance Tests
3.1.1 Introduction
These tests concentrate on verifying the functionality of the relay is as expected. It focuses on:
Verifying that the technical parameters are theoretically as expected, eventually referring to an order
book. This is mainly of importance if the protection type is selected for specific applications. This
is a pre-test phase, no real tests are performed for this.
Verifying the general functional characteristics against specifications through analytic signals.
These tests are generally accuracy tests.
Typical parts of numerical protection should be checked during the functional conformance test. The
following four points are important:
1. Protection functions
* Technical parameter (accuracy of pick-up values and characteristics, trip time, etc.)
2. Measurements
* Accuracy of measurements
3. Additional functions (for protection)
* Correct events in the operational and fault event list including the time stamp
4. Communication
* HMI interface for relay setting
* Protocol to SCADA (hardware - protocol)
* Other serial interfaces
- Interface to IED (intelligent electronic devices)
- Process bus (communication to CT, VT and breakers)
Functional conformance tests verify conformance by comparing test results with the specifications. For
most of these tests, the specifications are based on standards. If conformance is not fulfilled, this
should be considered as an error (in the relay or in the specifications). This is the main difference with
the function performance tests because here, not fulfilling a test, is considered as a limitation in
performance and not necessarily as an error.
3.1.2 Functional Conformance Test Programme
The test programme is detailed in Table 5, following.
12/26/2009 CIGRE 34.10

62
Table 5: Functional Conformance Test Programme
Nr Test Item Test Goal Test Programme Test Equipment Imp. Rem.
Requirements level1 ref.
A1 General technical Verification of the Briefly or check list: None (manual, A++ 1
parameters technical parameters: general data according the Catalogue) C-
generally and for standards:
each function inputs/outputs
electrical parameters
mechanical parameters
climatic parameters
check of protection
functions
setting range
operating times
Reset ratio
normal accuracy (under
influence of aux. dc voltage,
temperature, frequency)
additional function
types of alarms
features of fault records
measurements
type, tolerance
communication
type of interface
protocol
A2 HMI Correct HMI Via Integrated key pad and Test set (steady C++
communication with display: state signals), PC A0
relay function Activating and deactivating with setting
of functions programme
Change settings and
marshalling/masking
Read out of measurements
and events
Via PC programme:
Upload and download the
software or parameter
Similar tests as point 1
Check of the fault record
Saving of relay parameters and
cross check
A3 Binary inputs and Verifying all inputs Energise all inputs and outputs: Test set (steady C++ 5
outputs and outputs Inputs: Binary inputs state signals) A0
Outputs: Alarm and trip
relays, LEDs
1
A=Application, C=Certification. ++=very important; +=important; 0=neutral; -=not important; --not applicable
12/26/2009 CIGRE 34.10
63
Continuation of Table 5: Functional Conformance Test Programme

Requirements level1 Ref.
A4 Characteristics and Verifying Tests should be performed Test set C++ 2,5
performance of characteristics and separately for each function: (commonly steady A0
protection functions performance against Test of adequate points of state signals)
specification the characteristic (e.g.
inverse time, impedance,
etc.
Measuring the pick-up and
drop off values and
accuracy calculation
Measuring the operating
time
A5 Event logging, fault Check of the correct Activating each function Test set (steady C+ 3,5
record events and fault separately state signals) A0
records Read out the event list
Check the fault records
(correct scaling, trigger
points, marks)
A6 Measurements Accuracy check of Injection of voltage and currents Test set (steady C0, 5
measurements and read out of all state signals) A0
measurements
A7 Communication Verify and check the Check of the interface for Protocol test C++ 4
communication time synchronisation system A0
interfaces (IRGB, DCF 77,etc.)
Check of SCADA interface
(test conditions depend on
the defined interface, Point
a) is standard, b) and c) can
be optional)
a) alarms
b) measurements
c) fault records
Inter-relay communication
(Check of transferred
signals - blocking or
release- , measurements)
Remarks:
1. These tests have the characteristic of a review and should be done briefly. A check list is a recommended
method.
2. It is recommended to perform these tests under steady-state conditions. It is only necessary to verify
selected points of the relay characteristic.
3. The event lists and the time stamps should be checked for correctness. For the fault records, the proper
scaling is important.
4. The communication test helps to verify the communication interfaces. The test of the SCADA and the other
interfaces should be performed, if they will be used.
5. All these tests can be performed together.
1
12/26/2009 CIGRE 34.10
64
3.2 Technological Conformance Tests
3.2.1 Introduction
In the technological conformance tests, the hardware and software concept of the relay is tested. These
tests are more from a technological perspective and not from a functional perspective. Stress tests are
performed on the hardware to evaluate the long-term quality of the concept. These tests are divided
into four parts:
1. Electrical safety: thermal and dynamic withstand, burden, insulation
2. Environmental tests: how is the immunity of the protection against external influences such as
climatic conditions, EMC, vibration/shock during use and transport, seismic resistance
3. The quality in terms of reliability: These tests aim to evaluate the long-term quality of the concept.
Since a digital relay is conceptually and technologically different from older techniques, another
approach can be expected. The concern here is for hardware and software reliability.
4. The quality of the self-supervision: Since maintenance strategy will be based on this item, it will be
necessary to give attention to this important feature. This function is rather new and therefore
quality requirements are not well established. In section 2.4, an approach is developed.
A description of the different tests is given hereafter.
3.2.2 Technological Tests: Verifying Hardware Quality of Concept

These tests have been in existence for quite some time in IEC product standards in the IEC 60255
series. Therefore, more detail can be provided for these tests than other tests referred to in this paper.
EMC-tests have also existed in IEC product standards in the IEC 60255-22 series. Although these
standards are well-established, they are now updated to relate to the newly completed standards in the
IEC 61000-4 series and the EN 61000-4 series.
In Europe the prEN 50263 is in preparation as a product standard. This standard presents the minimum
requirements for relays for CE-marking; the standard indicates that the environment where the relays
are used may put more severe requirements on the relay. The prEN 50263 will be further developed in
a parallel voting procedure with IEC 60255-26.
The test programme is detailed in Table 6.
12/26/2009 CIGRE 34.10

65
Table 6: Technological Tests: Verifying Hardware Quality of Concept

Requirements level1 ref.
B1 IEC 60255-6 Markings Check of markings on relay and in - C++
documentation A++
B2 IEC 60255-6 Thermal measurement of max. allowable climate chamber, C++ 1
requirements temperatures at max. ambient temperature A-
verification of temperature sensors
range (operation and storage)
B3 IEC 60255-6 Input transformers Thermal withstand values of input generator C++ 1
energising quantities A--
B4 IEC 60255-6 Input transformers Short-time thermal withstand values generator C++ 1
of input energising quantities A--
B5 IEC 60255-21-1 Vibration test Mechanical resistance to sinusoidal vibration table C++ 2
Class 1 vibration vibrations A-
response and
vibration
endurance
B6 IEC 60255-21-2 Shock and bump Mechanical resistance to shock and shock table C++ 2
class1 shock test bump A-
response, shock
withstand and
bump test
B7 IEC 60255-21-3, Seismic test Mechanical resistance to single axis seismic table C++ 2
class 1 in X- and sine sweep A-
Y- axis
B8 IEC 60255-6, one Current input Limiting dynamic value generator C++ 1
half cycle test transformers A-
current with peak
value at least 2,5
the short time
thermal withstand
current
B9 IEC 60255-6 Rated burden Power consumption of input current standard C+
circuits and auxiliary circuits measuring A+
equipment
B10 IEC 60255-6 Insulation 50 or 60 Hz dielectric strength test generators C++
test A+
insulation resistance
impulse voltage test
spacing
B11 IEC 60255-22-1 EMC immunity Damped oscillatory wave test at test generators C++ 3, 4
class 3 100 kHz, 1 MHz, 10 MHz and 50 A+
IEC 60694 MHz
B12 IEC 60255-22-4 EMC immunity Fast transient test test generator C++ 3
class 4 A+
IEC 61000-4-4
class 4
1
12/26/2009 CIGRE 34.10
66
Continuation of Table 6: Technological Tests: Verifying Hardware Quality of Concept

Nr Test Item Test Goal Test Programme Test Equipment Imp. Rem
Requirements level1 Ref.
B13 IEC 60255-22-5 EMC immunity Surge test test generator C++ 3
(in progress) A+
IEC 61000-4-5
class 3
B14 IEC 60255-22-6 EMC immunity Conducted radio interference test test generator C++ 3
(in progress) A+
IEC 61000-4-6
class 3
B15 IEC 60255-2 class EMC immunity Electrostatic discharge test test generator C++ 3
3 A+
IEC 61000-4-2
class 3
B16 IEC 61000-4-11 EMC immunity Variations and interruptions in AC test equipment or C++ 3
for AC and DC auxiliary voltage set-up A+
IEC 60255-4 and
IEC 60255-11 for
DC
B17 IEC 61000-4-3 EMC immunity Electromagnetic fields anechoic room C++ 3
class 3 and test generator A+
ENV 50204 class 3
B18 IEC 61000-4-8 EMC-immunity Power frequency magnetic fields induction coil C0 3,5
class 5 (50 or 60 Hz) A0
B19 CISPR11, class A, EMC-emission Conducted RF interference on anechoic room C++
group I power supply terminals and radiated and antennas A+
interference
IEC 60555-2 Harmonics for AC supply
B20 CISPR 14 EMC-emission Flicker flicker meter C++ 6
A+
Remarks:
1. Tests 3, 4, 5, 6, 7 and 8 are transformer related and need not be repeated on each relay.
2. Vibration response, shock response and seismic tests are conducted with the relay energised, all
other tests are conducted with non-energised relays and verification of measurements after the tests.
3. Acceptance criteria for immunity tests: see Table 7.
4. Tests at 10 MHz and 50 MHz only for equipment to be used with GIS-equipment
5. Pulse magnetic field and oscillatory wave magnetic field tests according to IEC 61000-4-9 and IEC
61000-4-10 respectively may also be considered for equipment intended for HV-substations.
Another possibility is to test the digital protection equipment during load and short circuit test for
the switchgear equipment on which the protection equipment is built (provided that a representative
configuration is made) according the requirements for secondary equipment in IEC 60694.
6. Discontinuous interference (clicks) can occur, for instance, in equipment provided with heater
elements that are operated by thermostats.
1
12/26/2009 CIGRE 34.10
67
Function Criterion
Command and control 1
Measurement 2
Counting 1
Data transmission 2
Information and data storage protection 1
on line 1
Processing
off line 3
Monitoring 2
Human-machine interface 3
Self-diagnostic 2
Criteria of recommended severity level according IEC 61000-4-1
1. Normal performance within the specification limits
2. Temporary degradation or loss of function or performance which is
self-recoverable
3. Temporary degradation or loss of function or performance requiring
operator intervention or system reset
4. Degradation or loss of function which is not recoverable due to
damage of equipment (components) or software, or loss of data
Table 7: Acceptance Criteria for Immunity Tests
3.2.3 Technological Tests: Reliability Assessments

Reliability assessment is a complex matter and verification is even more complex. As digital
protection uncouples components from functions, software and hardware reliability has to be analysed
separately. For reliability of digital protection, the following aspects should be considered:
an increase of functional complexity (see also multi-functionality)
less hardware redundancy (one processor) but more reliable components with lower material ageing
the relay and its reliability are self-supervised. This means that if the relay is no longer reliable, an
alarm can be raised and the relay immediately repaired. The increase of availability that is obtained
in this way opens the door to other maintenance concepts. Of course, the effectiveness of self-
supervision largely determines the content of these new concepts. Due to its importance, self-
supervision is described separately in the following section.
Reliability assessment is generally a theoretical study. It is, however, inherent to a product and the
strongest determining factors lie in the design and manufacturing phases. IEC TC95 developed a
project draft about Predicted Availability, Reliability and Maintainability of Static Protection
Equipment [Ref 3] which gives substantial information on this matter. It is also proposed to divide
equipment into reliability classes.
It will be very difficult for users and/or third parties to make reliability calculations because component
failure rates and functional links are not often known and are difficult to obtain from manufacturers.
The reliability assessment of a protection equipment shall be both qualitative (Failure Mode and Effect
Analysis, FMEA) and quantitative (Parts Count calculation method and Fault Tree Analysis, FTA).
Internationally recognised predictive calculations (e.g. MIL-HDBK-217) are generally considered
12/26/2009 CIGRE 34.10

68
extremely pessimistic (up to factor 10 worse than reality). The accuracy of the data bank used will
reflect strongly in the prediction calculations.
One way of receiving some indication is to perform a reliability audit at the manufacturer, verifying:
their A.R.M. approach
the quality of the components used and the validation process before use (thermal ageing,
functional test, etc.)
the software development philosophy.
One should realise the complexity and the costs involved in such an audit.
Since the work on these two items, in part 1 Analysis of Specific Items in Numerical Protection
Influencing Protection Testing" is not yet completed, it is not yet possible to define a guide for the
assessment and/or a guide for tests. A very important missing link is the requirements of the
assessments or tests that have to be performed:
Required minimum failure rates that can be checked by calculations or by tests such as simulation
in Monte Carlo models, and/or
Required SIL-level (safety integrity level) for which draft standards give the specific measures that
have to be made on a system level to meet this requirement. A SIL classification can be derived
from a risk classification diagram as described in DIN V 19250 and draft IEC 61508. The
weighting factors are those that consider personnel safety, production and equipment loss,
environment, frequency of demand, potential extent of human injury on demand, duration of
presence in danger zone, possibility to avert hazard and potential production and equipment loss.
Having decided on a certain SIL-classification, the next decision is to choose the methods of
evaluation for compliance to the standard. A logical step uses the methods described in the (pre)
standard DIN VDE 0801/A1. The number of faults allowed (detected and/or not detected) is given,
as is the allowed degradation of function, including the method and depth of the checks and
monitoring functions that are performed.
3.2.4 Technological Tests: Quality of Self-Supervision
Self-supervision facilities are intended to improve availability, security and dependability of the
equipment. However, the added complexity may actually lower the overall reliability, and make it
increasingly important to increase maintenance and test intervals. Since the self-supervision facilities
have been developed very recently, the test items are given as examples. Reference to tests is also
given in Table 3 in section 2.4 on Self checking features, where the tests are separated into off-line
and on-line.
12/26/2009 CIGRE 34.10

69
Nr Test Item Test Goal Test Programme Test Imp. Rem.

(examples) Equipment level1 Ref.
Requirements
B21 Analogue Input Verifying Symmetry test (inject test set (with C++
supervision supervision for symmetric signal with 2 harmonic A+
analogue inputs phases switched ) injection
Input converter test possibilities)
(remove analogue earth
signal and create earth
fault)
Aliasing filter test
(harmonic injection)
B22 Power supply Verifying NC contact test (remove Voltage supply, C++
supervision supervision for supply voltage) DC voltage A+
power supply Level detection test generator
(decrease supply voltage)
Ripple detection (super
impose ripple on DC
voltage)
B23 EEPROM Remove detection (remove / C++ 1
supervision EEPROM) A0
Corrupt detection (insert
false EEPROM)
B24 Logic input Signal detection, Monitoring during e.g. NC / Remote control C++
supervision connections NO A++
B25 Logic output Signal detection, Monitoring during e.g. NC / Remote control C++
supervision connections NO commands A++
Table 8: Testing the Effectiveness of Self-supervision
Remarks:
1 These tests can cause unintended damage to the protection, since hardware changes are made in a
generally non-controlled environment. One should realise that a manufacturer would perform a
verification test when he would make such a change in his manufacturing process.
An approach between test and theoretical assessment is the method described in section 2.4. Based on
the information of the effectiveness of the self-supervision, a simulation model of the protection is
made, in which:
a determination is made of which function blocks are provided in the protection
a survey is made on how the function blocks are supervised and the effectiveness of self-
supervision of the various function blocks
various faults in the protection are introduced and the consequences of these faults calculated for
the reliability of the relay in a simulation tool with a random fault generator, in which the
effectiveness of the self-supervision for each functional block can be measured.
1
12/26/2009 CIGRE 34.10
70
the consequences for periodic testing are determined.
12/26/2009 CIGRE 34.10

71
3.3 Functional Performance Tests
3.3.1 Introduction
Each function of a numerical relay has to be tested after design changes. These tests should verify the
function itself, primarily without the influence of other functions as far as practical.
The tests address three main goals:
1. The software should be designed correctly against the specification.
2. The software should be stable for standard functions of the application.
3. The function shall fulfill all expected conditions for the intended application.
Unlike conformance tests, where there are generally no expectations specified, the function
performance tests are evaluated based upon the expectations. Unlike conformance tests, there are
generally no expectations specified. The expectations are more subjective and are determined by:
common acceptance. For example, it is accepted how a permissive overreach scheme should
operate.
functional goal (instead of conceptual solution). For example, a transformer differential protection
should be stable on inrush, although it is generally specified how harmonic blocking is achieved.
application requirements. For example, proper phase selection over a wide range of network
conditions when single phase tripping is applied.
The parameters of the evaluation are often the basic requirements of the protection: speed, selectivity,
and functional reliability (security, dependability). These aspects need to be maintained over a wide
range of network and setting parameters.
For relays based on artificial intelligence, functional performance tests could eventually replace
functional conformance tests almost entirely. The non-analytical and fuzzy approach could probably
be only vaguely specified, except for its functional goal.
3.3.2 Functional Performance Test Programme

See Table 9 for the details of the test programme.
12/26/2009 CIGRE 34.10

72
Table 9: Functional Performance Test Programme

Nr Test Item Test Goal Test Programme Test Equipment Imp. Re
Requirements Level1 mR
ef.
C1 Single parameter Dependency of Tests with extreme settings (Minimum, Test set, Signal- A++ 1
influence tests accuracy outside Maximum) (Network) C++
of reference Tests with sub-harmonics and higher Simulators with
conditions harmonics dynamic
Tests frequency deviations (also out of simulations
specified range)
Tests with DC-components in currents 3-phase signal
Tests with CT-saturation and remanence generator
Tests with CVT-simulation
Tests with non linear arc resistance
Tests with inrush simulation
Tests with high frequency transients
Tests with (analogue) signals outside
the input ranges
C2 Application tests Check of the Simulation of the power system Test system with A++ 2
correct behaviour conditions, which are relevant for the dynamic C+
of the tested type of the function (SIR, Rf, etc.) - (transient)
function for the tests which give the necessary simulations
specified power information for:
system condition behaviour of the function External Binary
outputs to other connected I/O system
(sub-) functions
outputs to binary or analogue
channels
outputs to communication
channels
outputs to event and disturbance
recorders
Remarks:
1. These tests include ranges outside the specifications and the results shall show the deviations of
operating and resetting values and times, and their limits. The test items are function specific. For
logical functions, other conditions such as dc levels and chattering of the inputs are important.
2. During these tests, a maximum number of functions should be active and the combination of the
types of parallel operating functions should be changed.
1
12/26/2009 CIGRE 34.10
73
3.4 Scheme Performance Tests
3.4.1 Introduction
The purpose of scheme testing is to verify the performance of the scheme. Correct interaction of all the
protective functions and their associated logic need to be checked for correct operation. The sequence
of events needs to be checked to include the operation of inputs, outputs and protection functions along
with the associated logic.
The necessity for scheme testing is largely generated by the multi-functionality of the protection
equipment. In the function performance tests, all functions have been tested separately. Here, the
concern is how the performance is influenced when all functions are in service and how they interact.
It is of course impossible to test all the functional combinations that users might apply. Therefore, the
scheme test should be considered as a sample test.
Scheme testing is very important for application testing. Scheme testing should include as many
components as possible that will be used in the actual installation. A real-time simulator should be
used to simulate actual network conditions. If the protection scheme is to be used with a
communication channel, it should be tested with the communication channel. In a lab environment, the
communication channel may be simulated with an actual propagation delay. To check the operation of
the scheme with the communication channel, both ends of the scheme should be tested simultaneously.
To achieve this, satellite synchronisation can be used.
For certification tests, the scheme should include the maximum number of protection and control
functions. It is not possible to simulate all possible combinations of logic. Therefore, for certification
tests, typical logic should be used that can exercise all the different types of logic, such as AND, OR
and NOT logic. For application tests, the actual configuration should be tested.
3.4.2 Scheme Performance Test Programme
The test programme is detailed in Table 10.
12/26/2009 CIGRE 34.10

74
Table 10: Scheme Performance Test Programme

Nr Test Item Test Goal Test Programme Test Equipment Imp Rem.
Level1 Ref
D1 Scheme connection Check electrical Check proper connection between Scheme diagram A++ 1
and setting connection different modules and test and HMI C+
verification instruments
Confirm the settings on the various
modules and logic
D2 Performance test Check the performance Test to check activation and Real-time A++ 2,3
of the scheme deactivation of various functions simulator C+
are possible and logic is HMI
programmable by marshalling
(masking) inputs and outputs
Test scheme with multiple real
faults to check proper sequence of
operation which includes
Affect of binary inputs on the
scheme, e.g. receipt of POTT
signal, autoreclose in progress etc.
Trip and close operating time
Timing of all inputs and outputs
Correct sequence of operation with
other functions, e.g. reclose, trip
and synch check
Correct functioning of scheme
logic
Test scheme with communication
channel to check proper sequence of
operation between functions and
inputs and outputs
Operating time of various functions
and inputs and outputs
Proper interaction between various
functions and inputs and outputs
Inputs, outputs and functions
perform as per marshalling
(masking) of I/O
Affect of max. and min
communication delay on scheme
operation
1
12/26/2009 CIGRE 34.10
75
Remarks:
1. Include as many modules possible in the scheme.

2. For certification tests, the maximum functions should be activated and all logic operations (AND,
OR, NOT) should be exercised. For application tests, id is advisable to concentrate on the used
scheme(s).
3. In lab testing, a communication channel should be simulated with the proper delay.
12/26/2009 CIGRE 34.10

76
3.5 Upgrade Type Tests
3.5.1 Introduction
Upgrade type tests are linked to the fact that the software can change independently of the hardware as
explained in section 2.7 and that software evolution should normally not be considered a new product.
In fact, it is important not to do so because upgrades can be rather frequent and employ only small
changes (e.g. correction of bugs). It would be too costly to repeat the entire type test programme for
minor changes. Therefore, a reduced upgrade type test programme is proposed in this chapter.
From an application perspective, the most important factor in determining whether or not a reduced
type test programme is acceptable is the type of change itself: does it concerns a small bug correction, a
new introduced function, a rearranging of a function or a completely revised software? These factors
are subjectively linked, not objectively, to the typical use of the relay and to economic considerations.
From a certification perspective, each specific version should theoretically be considered as new but, in
reality, it also depends on the philosophy of the manufacturer and their requirements. Manufacturers
often include their philosophy in the version identification. For example, in an XYZ version, an X
value change means a drastic change, necessitating a complete new type test programme. A Y value
change may mean a smaller change, justifying a reduced test programme. A Z-value change means a
minute change that is transparent to the operation and, therefore, needs no special tests.
Fortunately, the perspectives of the user, the certifier and the manufacturer are similar, therefore
conflicts on the necessity of performing complete, reduced or no testing at all are generally avoided.
If a reduced testing programme seems acceptable, this chapter provides guidance on the content of
such a test programme.
3.5.2 Upgrade Type Test Programme

A reduced type test programme for upgraded relays is described in Table 11.
12/26/2009 CIGRE 34.10

77
Table 11: Upgrade Type Test Programme

Requirements level1 Ref
E1 Testing the Verification of the correct Item specific conformance tests item specific C++ 1
upgraded items functioning of the changed A0
items
E2 General Verification that no other Reduced type testing programme: automatic testing C++ 2
performance of the function has been degraded function or scheme tests network simulator A+
relay -probabilistic approach-
E3 Application Verification that the Configuration exercise and automatic testing C- 3
compatibility version corresponds to user verification via scheme tests (replaying reference A++
specific schemes database)
E4 Testing new Compatibility test Using HMI with upgrade C++
software with HMI A+
E5 Performing periodic Verification that the Performing periodic test routine periodic test C--
test routine periodic test programme equipment A+
still works on the upgraded
version
Remarks:
1. The test programme is defined by the type of upgrade that was performed and can range from the
verification of a specific item to the test of a complete function, or even to the complete protection
if it has been totally changed (example: new processors). These types of tests imply that the tester
is aware of all changes that have been made to a specific protection.
2. It is an impossible task to test every possible combination of configuration, functions, settings and
input conditions to determine that no other functionality has been deteriorated by the
implementation of the upgrade. Therefore probabilistic testing is advisable, taking a representative
sample of conditions for which the expected relay response is known, and verifying proper
operation. The expected relay response can be that of the previous version of the relay. If a
difference in response is noticed, it should be determined if the difference is explainable by the
introduced change.
3. It is important to verify that changes do not effect input/output or user-specific internal logic. Such
a change would not be considered an error by the manufacturer, but could have severe
consequences on the application of a relay. For example, changing the parameter address or
meaning (complement) could lead to unexpected results.
1
12/26/2009 CIGRE 34.10
78
3.6 Acceptance Tests
3.6.1 Introduction
Acceptance tests include those tests performed by the customer, both at the delivery of a new relay and
upon receiving an upgraded version of the relay. Several scenarios for the acceptance tests are
possible:
The acceptance test can be performed by the manufacturer before or after shipping.
The protection can be shipped directly to the utility or to a contractor charged with the bay
integration. In the first case, the protection may be a spare, or replacement, protection. In the latter
case, the acceptance test (or one part of the acceptance test) can be performed either by the
contractor or by the utility on the site of the contractor.
If the utility buys a complete bay, the acceptance test has to be performed for the bay. It must
include acceptance tests for the protection installed in the bay.
If the manufacturer has a quality assurance system acknowledged by the utility regarding
assembling and shipping procedures, it is possible to skip acceptance tests for the protection and
perform only sample tests. In this case, the quality system must ensure that all the tests required be
correctly performed, acknowledged and documented by the manufacturer. It is then assumed that
the protection complies with the specifications and that they have been shipped correctly. The user
checks the test programme of the manufacturer for completeness.
In principle, the acceptance test is a reduced part of the type test under special, user-defined application
conditions. Therefore, the number of settings and functions used will be reduced. Conversely, special
conditions, which were only generally included in the type test, will need to be investigated.
The user will initiate the acceptance test:

for a new product
for the upgrade of an accepted product with new function(s)
for a change of the function of the software
3.6.2 Acceptance Test Programme

The tests are described in Table 12.
12/26/2009 CIGRE 34.10

79
Table 12: Acceptance Test Programme

Nr Test Item Test Goal Test Programme Test Equipment Rem
Requirements Ref
F1 Order Conformance Check that the Visual verification of none 1
Test protection corresponds housing, connectors,
to the specification Verification of the type and
referenced in the order version (both hardware and
software)
Verification if all
documents are included and
whether they meet the
requirements
Verification of user-specific
demands (for example pre-
programming)
F2 Functional test Verification of the Verify whether the test set (V,I signals 1,2,3
correct function of the protection responds at industrial
protection to avoid correctly to stimuli. frequency)
installing defective Perform a reduced set of
protection in a bay tests, injecting currents and
voltages
F3 Test after bay Verification of the Verification of the input 3,4
integration compatibility between circuits, logic input and
protection and bay. output circuits and of the
trip circuits
F4 Upgrade Verification of proper Verification of the 5
Introduction tests installation of the manufacturers advise
upgrade Perform F1,F2 and F3 again
Remarks:
1. See different possible scenarios described in section 3.6.1.

2. The importance level of the functional acceptance test depends partly on the tests performed by the
manufacturer.
3. The functional test can also be performed after the bay integration, depending on the
commissioning procedure of the user.
4. This test can be performed by the contractor. It corresponds to a pre-commissioning test.
5. Only for upgrades on devices that have already passed the acceptance tests.
12/26/2009 CIGRE 34.10

80
3.7 Commissioning Tests
3.7.1 Introduction
Commissioning tests are performed prior to connecting the high voltage element to the electrical
network. During commissioning, it is necessary to ensure that the interconnection between all
equipment on the bay is correct.
CT and VT
Circuit breaker
Bay control
Protection
Teleprotection equipment
Communication to the control or telecontrol centre
Communication to the analysis centre
Setting check
The commissioning tests for digital protection are not very different with respect to conventional tests,
except for the testing of connections to the remote communication centre and the way the tests,
themselves, are performed. The method of performing the tests changes due to the following:
Additional internal information is available which can be used for the tests. This reduces the need
for external measuring apparatus.
Setting points cannot easily be found by changing the setting itself, as was the case with
potentiometers. But locating the setting points is no longer needed because the values at each
working point are generally available.
Additional functions are integrated in one device, making a scheme approach necessary. For
example, instead of injecting current into the secondary side of the intermediate CTs on transformer
differential protection, tests are now performed on the primary side (software CTs) and the injected
signals need to compensate for amplitude and phase corrections.
As multifunction protection permits to integrate a much larger part of the scheme (wiring, additional
relays), it is possible that a larger part of the scheme tests are realized in a pre-commissioning phase,
e.g. during acceptance tests.
3.7.2 Commissioning Test Programme

The test programme is described in Table 13.
12/26/2009 CIGRE 34.10

81
Table 13: Commissioning Test Programme

Nr Test Item Test Goal Test Programme Test Equipment Rem.
Requirements Ref
G1 Relay installation Confirmation of the correct Visual check of protection cubicle none
test (visual check) relay transport and Visual check of external wiring
installation Check of relay grounding
Check of supply voltage, DC and AC
Taking note of relay number, model
and version
G2 Analogue inputs test Check of hardware defects Injection of all voltages and current rated Three phase test 1
values and read each value on the HMI system
display
G3 Binary inputs test Check of hardware defects Activation and deactivation of all binary none 2
inputs
G4 Relay Checking the correct relay Download setting values none 3
communication test communication from the Read-out the downloaded values
HMI and serial interfaces
G5 Relay functional Checking the correct Test on different zone - phase faults Three phase
test operation of the different Test on single and three phase faults automatic test
relay functions, trip relays, Test of the chosen scheme protective system
auxiliary relays, alarm Test with forward and reverse faults
relays, LEDs signalling Tested items:
and downloaded settings Protection functions
Operation times
Protection scheme
Reclosing function
Synchronising function
Teleprotection function (send
and receive)
Fault locator
Events recorder list
Fault recorder (oscillography)
Circuit breaker failure
Fault reports
Alarms
G6 Complete switch- Checking all cabling Field check of the circuit breaker Three phase test 4
bay protection between the relay and CTs, behaviour, single line trip, three phase system
system test VTs, circuit breaker trip trip, reclosing
coil, teleprotection cubicle
and control bay
G7 Final check (after Checking the correct real- Read-out the values of currents, voltages, none 5
connecting to the time direction of voltages active and reactive power on the HMI,
network) and currents against of the control or telecontrol
values
G8 Upgrade Verification of proper Verification of manufacturers
Introduction tests installation of upgrade advise
If setting or marshalling table is
changed, perform G2 to G7
If setting or marshalling table is not
changed only G4, G5 (reduced), G6,
G7 could be performed.
Remarks:
12/26/2009 CIGRE 34.10

82
1. Checking the injected values on the event recorder list

2. Checking the time - tagged activation/deactivation of inputs
3. Comparison of the two values
4. Verification of the circuit breaker time response
5. Print the V, I, and angle values
12/26/2009 CIGRE 34.10

83
3.8 Periodic Tests
3.8.1 Introduction
It has already been stated that periodic testing on numerical protection schemes can drastically
decrease due to the presence of self-supervision. Appendix 1 describes some methods to evaluate the
effect on periodicity.
In this chapter it is mainly the goal to concentrate on what type of tests could still be valuable and what
different approaches could exist.
Different approaches are possible for periodic maintenance depending on the type of relay, the
confidence in self-supervision and the way this supervision is taken into account (see appendix 1).
Some ideas are developed here, which can be used for periodic test philosophy:
A first periodic test programme, after a short period of service of the relay, in order to detect
possible faults after commissioning or latent defects in the devices.
A periodic monitoring which is a fast verification of the relay without injection equipment.
The normal periodic tests with a test set.
Finally, an integration of all this in a condition-based maintenance model.
The content of these different test programmes also could be different if self-supervision is taken into
account. Different test programmes could be proposed depending on the self-supervision features of
the different blocks, as defined in Tables 3 and 4 of section 2.4, and their effectiveness. Based on these
tables, a maintenance philosophy can be established ranging from full maintenance to zero
maintenance.
Only general ideas are given below. The actual test programmes and their frequency depends upon the
users interpretation of the different aspects.
3.8.2 Periodic Test After 1-2 Years in Service

The increased flexibility that has been achieved by the introduction of numerical relays has also given
rise to an increased amount of configurations and settings that the user must do. This, in turn, increases
the risk for incorrect configurations and settings, which may not always be detected during
commissioning tests.
It is also understood that manufacturers do not test all possible combinations that exist in a modern
integrated protection terminal. Some types of faults might be difficult to detect during commissioning
tests due to time limitations.
If the interval of periodic testing is extended longer than the manufacturer-guaranteed time and a fault
in the protection is detected, there might be some problem in convincing the manufacturer that it is a
guarantee matter since no fault was found when commissioning the relay at the time of installation.
12/26/2009 CIGRE 34.10

84
With the arguments given above, it could be wise to perform a second commissioning test several years
before the expiration of the guarantee. Examples of tests are given in Table 16, below.
3.8.3 Periodic Monitoring

As indicated in the last columns of Tables 3 and 4, verification on several functional blocks can be
based upon the readout of the actual measurements. For example, an important part of the analogue
measuring system can be verified by looking at the values given by the protection and verifying that
they correspond to the actual values. Using the fault records, the dynamic behaviour on the last fault
can also be checked. The readout may also be accomplished remotely.
Periodic monitoring involves all the verifications that can be accomplished by reading the relays
information, without requiring the use of an injection test set. Although it is not possible to check
100% of the protections functionality, this method can delay the necessity for periodic maintenance
with an injection test set. Such scenarios are already in use in some countries, e.g. the German
recommendation [Ref. 14]:
Each 2 years: periodic monitoring
Each 4 years: injection tests
3.8.4 Normal Periodic Tests

The motivation for performing periodic tests is to verify the proper operation of those functions
involved in fault clearance. As a minimum, it includes tests of those parts that are not supervised (see
Tables 3 and 4). The minimum tests required include control of the A/D-converter, verification of
settings, verification that remote alarm by the self supervision is received at the remote control centre,
certification of trip relays and of circuits between the protection and the breaker. Normally periodic
tests also include testing of the teleprotection schemes and the autorecloser.
The functionality of the A/D-converter is verified by secondary injection of current and voltage at 50
or 60 Hz and ensuring that the operating values are within the stipulated accuracy. It is not necessary
to check the characteristic since this is stable over time. Verification of the A/D-converter frequency
response (analogue initialising filter) is mainly required for disturbance recorder functions. These
types of tests require the injection of harmonics at the same frequency as the rated frequency of the
filter.
The verification of the signal from the self-supervision to the remote control centre is imperative if the
interval of periodic tests is increased considerably as compared to the time interval for
electromechanical or static relays on base of the existence of self-supervision.
3.8.5 Condition-based Maintenance

When condition-based maintenance is applied, no periodic tests are performed. The course of action to
determine if maintenance should be performed includes fault analysis where the disturbance recorder,
relay indications, and event lists provide critical information.
12/26/2009 CIGRE 34.10

85
By intensive fault analysis, it is possible to determine which relay should be activated for a given fault.
For example, a line fault with a relay at the adjacent station that does not start, can be a basis for
judgement that maintenance is needed for that particular relay.
These techniques require good analysis tools and probably also a fault locator in order to capture
accurate information of the fault location.
12/26/2009 CIGRE 34.10

86
Table 14: Periodic Test Programme

Requirements Ref.
H1 Verification of Verification of the scheme Verification of performance of the Relay test 1
scheme according to the algorithm equipment for
performance within application Verification of settings injection of
1-2 years after Verification of extra functions e.g. secondary currents
commissioning tests switch onto fault logic, power swing and voltages. It is
detection, local acceleration logic, preferable to use
current reversal logic, weak-end transient fault data
infeed logic, fuse failure supervision or recorded fault
functions, power system supervision data from actual
logic, autoreclosing and logic, event faults.
recorder, disturbance recorder, etc.
Verification of communication logic
fused
Energising and de-energising
auxiliary tripping and signalling
relays
Verification of trip logic philosophy
Verification of self supervision e.g.
that alarm will be received for all
faults that should give alarm,
controlling that the protection will be
blocked by the supervision for right
type of fault
H2 Periodic monitoring Verification of the scheme Read and verify actual measurements None
according to the Read and verify settings
application without Read and verify last fault events and
injection tests records
Evaluate alarm list
Tripping test initiated by protection
scheme (with automatic
autoreclosing)
Switch protection off and verify
supervision alarm is received at
control centre
H3 Verification of Verification of functions Verification of function performance Relay test 2
scheme that cope with fault Verification of trip logic equipment for
performance more clearance Energising and de-energising injection of
than 2 years after auxiliary tripping and signalling secondary currents
commissioning tests relays and voltages. It is
Check that circuits from protection preferable to use
relay to the breaker coil are in tact. modelled fault
Check of power supply level data or recorded
Verification of settings fault data from
actual faults.
12/26/2009 CIGRE 34.10

87
Continuation of Table 14: Periodic Test Programme

Requirements Ref.
H4 Verification of self Check of the functionality Depends on what is supervised and the 3
supervision effectiveness of the self-supervision and
the alarm to the Control Centre. For
example, the following functions used to
be supervised and are suitable for the
user to check.
Analogue input channels
Loss of power supply
H5 Condition-based To identify faulty Using a disturbance recorder, relay
maintenance protection before a fault indications and event lists, analyse what
occurs on the protected has happened and give order for
object maintenance when needed
Remarks:
1. A complete maintenance test should be done within 1-2 years in order to verify the overall function
of the protection scheme before the manufacturer guarantee expires.
2. Verification of settings could preferably be done with remote readings from the relay. Special
notice should be given to the eventual drift of the performance characteristics of the A/D converter.
3. Verification of self-supervision is not proposed to include verification of software faults such as
correct behaviour of ROM, RAM, EEPROM, etc. This is proposed to be performed once during
commissioning tests.
12/26/2009 CIGRE 34.10

88
4. Appendix:
Different Approaches to Determining the

Interval and Content of Periodic Testing
12/26/2009 CIGRE 34.10

89
4.1 Interval Based Upon Reliability Analysis
4.1.1 Introduction
The main topic of this paper will be to discuss the influence of new microprocessor techniques on
maintenance philosophy at a system level.
The focus will be on three main areas:
1. The influence on technical performance areas such as availability, security and dependability.
2. The influence on the long-term stability of components and programmes.
3. The influence on the management of protection.
Some aspects of test procedures will be discussed shortly. The lack of statistical data on the benefit of
self-supervision causes the judgement to be more subjective than objective.
4.1.2 The Influence of Self-supervision on Availability, Security and Dependability
4.1.2.1 General
Today's microprocessor technology permits self-supervision without the need for any additional hardware. The
ability to detect internal faults in the relay depends upon the complexity of the relay. Less complex functions,
such as overcurrent protection, can be self-supervised to quite some depth. However, for more complex
functions such as distance protection or generator protection, the depth of self-supervision cannot be as great
because of the high demand for dependability.
Without self-supervision, the Mean Time To Repair (MTTR) is approximately one year when the maintenance
interval is two years, since a fault will most likely not be detected until the next maintenance cycle. This
statement applies mostly to a failure to operate. However, it can also apply to other types of failures in order to
show the effectiveness of the self-supervision. With self-supervision, the MTTR could be 2 days instead of 365
days, which is a significant improvement. Of course, the figures should not be taken as an absolute value. For
example, the final result depends upon the user's spare parts policy and their availability. But the fact remains
that the improvement of the availability will be significant.
4.1.2.2 A Simple Model for Optimising Periodic Tests by Calculating the Unavailability
In order to show the effect of self-supervision, a simple Markov model has been developed based on
reference 1, which can be used to determine the interval of periodic testing in order to achieve a pre-
defined target of maximum unavailability. The model is based on a probability approach and uses the
simple assumption that the condition of the protection relay can only consist of two states: not faulty
and faulty (refer to Figure A1).
1
NOT 2 FAULTY
FAULTY
Figure A1: 1 = fault rate of the relay; 2 = repair rate of the relay
The evaluation of the model is also based on the following assumptions:
12/26/2009 CIGRE 34.10

90
The fault rate 1 is assumed to be constant, i.e. no consideration is given to the effects of
debugging at the beginning of the life cycle and of the wear out period towards the end of the life
cycle.
The protection relay is not faulty at the time t = 0.
No consideration is given to the effect of repair time, i.e. MTBF = MTTF = 1/.
The fault rate, 1, can be expressed as: number of failures per unit exposure time
number of components exposed to failure
The total fault rate, (t), for a system can consist of two conditions, faulty (1) and a repair rate, i.e. the
probability to move from a faulty to a not faulty condition (2) can be estimated as =1+2.
In some cases no function or available procedure exists to move from the faulty condition to the not
faulty condition. This is the case for relays without self-supervision and for electromechanical relays
that are not periodically tested. A fault in the relay will most likely be detected when an incorrect
operation of the protection occurs.
In this case, 2 is not present and the total fault rate for the system is = 1. The Mean Time Between
Failure (MTBF) can be determined by summing the Mean Time To Failure (MTTF) and the Mean
Time To Repair (MTTR), i.e. MTBF = MTTF + MTTR, where MTTF = 1/1 and MTTR = 1/2.
For relays without self-supervision, the MTTR can be as high as half the time for periodic tests since
no inspection of the relay is expected in the interval between the periodic tests. As an example, the
MTTR could be one year as a mean value when the interval for periodic tests is two years. With a
MTTF for electromechanical relays equal to 80 years, this gives us a MTBF of 81 years. Reliability
calculations with the two MTBF figures show that the change of MTBF from 80 to 81. This change
will not affect the calculation of the unavailability in the proposed model because the one-year change
is comparatively small when compared to the MTTF of 80 years. Therefore, the change of will be
small. For this reason, and by convenience, the numerical calculation does not take the effect of MTTR
into account when calculating the unavailability.
For relays with self-supervision, the probability for the faulty relay to move from the faulty condition
to the not faulty condition is determined by the repair rate 2. It is thus assumed that the faulty relay
will be repaired immediately. If it is considered that the MTBF can be calculated as
MTBF = MTTF + MTTR, and assume a MTTR equal to 2.5 days, it is found that the MTTR will be
6.85* 10 3 years. This is a very low value compared to a MTTF of 74 years for numerical relays,
which corresponds to a fault rate = 0.01351 ( years 1 ) and will not affect the calculations. Most
utilities have organised their maintenance in such a way that the MTTR will be relatively short when
compared to the total time of operation. Therefore the influence of MTTR on the reliability
calculations for relays with self-supervision can be neglected.
Based on the assumptions, and with reference to [18], the reliability for protection can be expressed as:
t
1t
R1( t ) = e 0 = e 1t (1)
12/26/2009 CIGRE 34.10

91
The reliability in this case is the probability that the system will perform the required function.
In cases with self-supervision, the repair rate (in this case the effectiveness of the self-supervision) has
to be considered. The reliability of condition 2 (lets call it the repair condition) can be estimated in the
same way as for R1, by substituting 1 with 2. The total reliability of a system ( Rs ) that consists of
two conditions (faulty and repair conditions), where the output of the system is dependent on both
conditions being fulfilled (moving from not faulty-faulty-not faulty) can be evaluated as:
Rs = R 1 R 2 (2)
The probability of having a failure in the protection (Q) is the complement to the reliability that can be
expressed as:
Q( t ) = 1 Rs( t ) (3)
The deduction of the expression of the unavailability for the different cases (with and without self-
supervision and with or without periodic tests) can, with reference to Figure A1 and equations1-3, be
expressed as follows:
Relays that are not periodically tested and without self-supervision
Because no periodic tests are applied and the protection does not have self-supervision, the fault
rate = 1 and the reliability can be expressed as:
R(t ) = e t (4)
and the probability to have a failure in the protection:
Q 1( t ) = 1et (5)
where t is the time of study.
Relays without self-supervision with periodic tests
The reliability for the fault condition 1 and 2 can be expressed as:
R1(t ) = e 1t (6)
2( t nT )
R 2(t ) = e (7)
where n is the number of realised tests at the time t (0 t T ) and T is the time between periodic tests.
The number of accomplished tests at the time t is given by the integer fraction n of t/T.
The reliability of the system (RS) can then be expressed as:
Rs( t ) = R1( t ) R 2( t ) = e 1t e 2( t nT ) (8)
By taking into consideration that = 1 + 2 and that the detection ability of tested protection is
2
= , the reliability of the system as function of time can be expressed as:

Rs( t ) = e ( 1 )t e ( t nT ) (9)
and the probability of failure in the relay will be:
Qs(t) = 1 e (1)t e (t nT ) (10)
where n is the integer value of T.
12/26/2009 CIGRE 34.10

92
Protection with self-supervision without periodic tests

For protection that contains continuous self-supervision where detected faults are corrected
immediately, the probability for operation can be expressed as:
Rs( t ) = e ( 1 )t (11)
where is the detection ability of the self-supervision in pu.(1). The probability of a fault in the
relay can then be expressed as:
Qs(t) = 1 e (1)t (12)
The influence of the self-supervision seen is that the fault rate, , drops from to (1-).
Protection with self-supervision with periodic tests
With the influence of both the self-supervision and periodic tests, the change of the relay from not
faulty to faulty can be expressed as:
1 = (1 ) (1 ) (13)
and the change from a faulty condition to a not faulty condition as:
2 = (1 ) (14)
The reliability for the system can then be expressed as:
Rs( t ) = e 1t e 2(t nT) = e (1)(1)t e (1) (t nT) (15)
The probability of a fault in the relay for the system can then be expressed as:
Qs( t ) = 1 R( t ) = 1 e ( 1 )t e ( t nT ) (16)
where = (1-)* is the portion of the faults that are not detected by the self-supervision, but detected
by periodic tests.
The mean value of the probability of having a failure in the relay can be calculated by the integration of
the Q (t), i.e.
t t 1
Qmean( t ) = 1
t UA( t ) dt (17)
t1
4.1.2.3 Input Data to the Calculation

The input to the calculation was carried out by using the statistical data of the behaviour of the 400-220
kV line protection for the Svenska Kraftnt (Swedish National Grid) during the years of 1985 - 1996 as
shown in Tables A1 and A2 below. The data in Table A1 represents the mean values of the individual
items of all relays. This data has been used as a reference.
Type of Operation Nfail Nunw Ncor Ntot

400 kV 43 36 1775 1874
220 kV 27 45 1631 1762
Number of operations 70 81 3406 3561
Table A1: The Behaviour of 400-220 kV Line Protection Relays in Sweden from 1985 - 1996.
Nfail = Number of failures to operate
Nunw = Number of unwanted operations
Ncor = Number of correct operations
Ntot = Total number of operations (not equal to Nfail+Nunw+Ntot, one item not stated in the table)
12/26/2009 CIGRE 34.10

93
The population of the statistical material that corresponds to Table A1 can be seen in Table A2.
Protection types Electromechanical Static Numerical Total

Relay years (Nry) 8902 2168 1063 12123
% of Nry 73.4 17.9 8.7 100
Table A2:
Population of the Statistical Material for the Reliability Behaviour
of the Swedish National Grid from 1985-1986.
Information has been received from ABB Automation Products AB on the behaviour of numerical
relays based on the field experience of approximately 5000 relays during the year 1997. The MTBF
was calculated to be 74 years. Using this value, the fault rate, R, is calculated to 0.01351. This value
is used to show the influence of self-supervision on the availability.
The different fault rate, , for Reliability, Dependability and Security has been calculated by using the
following expressions:
Ninc
Reliability: R = (18)
Nry
Nfail
Dependability: D = (19)
Nry
Security: S = Nunw (20)
Nry
Where: Ninc = Number of incorrect operations = (Nfail+Nunw)
Nfail = Number of failures to operate
Nunw = Number of unwanted operations
Nry = Total number of relay years
The values of the calculated fault rates have then been used in the Markov model described in section
4.1.2.2.
The detection ability of the self-supervision, , has a very high influence on the unavailability of the
protection. In order to show this, calculations have been made using three different values: = 0.7, 0.8
and 0.9, where = 0.7 means that the detection ability is 70%. In general, the user should be
conservative when choosing the value of until either the user or the manufacturer has collected more
experience on the effectiveness of the self-supervision.
The detection ability of the periodic test () also has a major impact on the calculation of the
unavailability. In general, the effectiveness of manual tests is high, but it is not 100%. In the
calculation, an effectiveness of 95% is used. This means that 5% of the faults in the protection relay
are not detected by periodic tests.
12/26/2009 CIGRE 34.10

94
4.1.3 Calculation of the Influence of the Self-supervision on Availability
4.1.3.1 Calculation When Single Relays Are Used
The effect of self-supervision on the unavailability has been calculated by using Reliability,
Dependability and Security and with different values of the effectiveness of the self-supervision
(=70%, 80% and 90 %).
The overall quality parameter Reliability, (R), has been used to calculate the unavailability. This,
together with the equations given in section 4.1.1.2.2 for the different unavailability cases over a 20-
year period, with given detection ability of self-supervision, = 70%, and the detection ability of the
periodic test, = 95 %, the result obtained is shown in Figure A2. For other cases where is higher
than 70 %, the result will be similar to Figure A2, except that the derivative of curve 2 and 4 will be
less. The only case shown graphically is with =70 % to facilitate visualisation of the principle.
0.25
0.22051
0.24 1. Relays without self-supervision
0.23 and without periodic tests
0.21
2. Relays with self-supervision and
0.2
without periodic tests
0.19
0.18 3. Relays without self-supervision
0.16 and with periodic tests
F2( t )
0.15
Probability of F2m( t ) 4. Relays with self-supervision and
incorrect 0.14
F1( t ) with periodic tests
operation (pu) 0.13
F3( t ) 0.11
5. Mean value of
F4( t ) 0.1 curve 3
0.088
0.075
0.063
0.05
0.038
0.025
0.013
0 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0 t 20
Time (year)
Figure A2: The Unavailability Due to Incorrect Operations for Relays With and Without Periodic Test and
Self-supervision. Curve 4 = Relay With Periodic Test and Self-supervision
The difference between curve 1 and curve 2 is the increased availability that is obtained with self-
supervision for protection that is not periodically tested.
12/26/2009 CIGRE 34.10

95
If the relays are periodically tested with an interval of every second year, the increased availability is
obtained by the difference of curves 4 and 3.
In some cases, the decreased probability of having a failure in the protection relay can be valuable. But
for most cases it is of more interest to use the increased availability to increase the interval for periodic
tests in order to decrease maintenance costs. This leads to the question of to what extent the interval
can expand without exceeding a pre-defined value of maximum allowed unavailability. A reasonable
assumption is to let the unavailability for relays with self-supervision expand to the level of the mean
value of the unavailability for the existing relays without self-supervision (curve 5 in figure A2).
Interactive calculations of the unavailability for relays with self-supervision and with periodic test
(equation 15) for different values on the effectiveness of the self-supervision (=70%, 80% and 90%)
have been performed.
Regarding the use of dependability and security to calculate the corresponding failure rate for
numerical relays, the assumption that the dependability and security for numerical relays have the same
distribution factor as the distribution factor for electromechanical relays has been used. The
D D
distribution factor is calculated as and .
R S
This gives the fault rate for a failure to operate as f = 0.45*0.025 = 0.012,
and the failure rate for unwanted operations as u = 0.52*0.025 = 0.13.
The result, seen in Table A3, is that the interval between periodic tests can be increased significantly as
compared to the reference case with a periodic test interval every second year.
4.1.3.2 Calculation of the Unavailability When Parallel Relays Are Used

In the case where there are duplicate or parallel relays and the relays are independent of each other, the
system unreliability can be calculated as:
Qsyspar = P1 * P 2 (21)
where P1 and P2 are the fault rate on each relay. This gives the probability that both relays are
unavailable at the same time. If it is assumed that the same fault rate for each relay, equal to
R=0.0124, the system fault rate, sys, for the relays in parallel is equal to 0.000155 ( R 2 ) for
electromechanical relays. This value has been used to calculate the mean value of the unavailability
according to equation (9) with T = 2, which is used as a reference value.
Calculating the fault rate, R, for relays with selfsupervision according to formula (21), and finding
the time, T, which gives the same unavailability as relays without self-supervision, that the interval
between periodic tests can increase to 8 years with the detection ability of the self-supervision =
70%.
Calculations with = 80% and = 90% show the interval can be expanded to 12 and 24 years,
respectively.
When moving to applications with parallel relays, one must beware of the risk that unwanted trips will
increase, in this case twice the time as for a single relay.
12/26/2009 CIGRE 34.10

96
4.1.3.3 Conclusions From the Model Used

Even though the algorithm is a rough simplification, the belief is that it can be accurate enough to show
that the interval for periodic tests can be extended considerably. The goal is to increase the interval of
periodic testing to the point where the unavailability is equal to relays without self-supervision. The
results are summarised in Table A3 below.
Type of = 70 % = 80 % = 90 %
Calculation
Reliability 9 13 26.5
Dependability 9 14 27
Security 9 13.5 26.5
Duplicated 8 12 24
protection
Table A3. Results of Calculations for the Interval of Periodic Testing (years)
As Table A3 shows, the maximum interval between tests are very much affected by the selection of the
detection ability of the self-supervision. A recent study of the reliability of relay protection from Japan
(ref. 3) points out that the effectiveness of the self-supervision was 87%. Based on this investigation, it
may be plausible that a detection ability of 80% would be a suitable figure to use until more experience
with the effectiveness of self-supervision is available.
If the detection ability is quantified to 80%, the interval between periodic tests could expand to 13
years. If the self-supervision includes system supervision, the detection ability might be higher than
80%. In the case of duplicated relays (Main 1 and Main 2), the influence of the self-supervision shows
that the interval for periodic tests can expand to 12 years with a detection ability of 80%.
4.1.4 Risk Management of Protection Equipment

With the information available from protection equipment such as indications and events recording,
together with information from a disturbance recorder, it is possible to conduct a manual evaluation of
the necessity of performing maintenance at a specific time.
For instance, consider a periodic time for maintenance of the protection every fourth year. Suppose a
fault occurs on the protective object in the third year with successful fault clearance. This could be
used as the basis for a decision on whether maintenance should continue according to plan, perform
maintenance in the fourth year, or to wait until the eighth year.
If the decision is to wait, there is a risk taken with regard to the dependability demand, and the risk
depends upon what has functioned. Since it is known the protection is operating and, taking the
circumstances and application into account, the risk may be acceptable.
Another way of managing the protection system is to change the settings to below the load level from
the remote control centre and let the protection trip. If the user doesnt want the object to trip, the
protection can be taken out of service before changing the settings. This can be done in connection
with normal maintenance of the breaker or line. It is doubtful that this can replace the traditional on-
site functional test, but it could become a good complement. The user will get the information that the
circuit breaker, the analogue inputs, the conversion, the numerical calculations and the output circuits
12/26/2009 CIGRE 34.10

97
operated properly. If a zero sequence measurement is included in the protection, it will not be tested in
this case.
12/26/2009 CIGRE 34.10

98
4.2 Test Interval Based Upon Economic Considerations
4.2.1 Economic Determination of the Interval for Periodic Tests

Deregulation of electrical distribution in many countries creates a sharper focus on the justification of
power system relays. In every application there is a need to find solutions at the lowest possible life-
cycle cost. It then follows that it is also of interest to study the feasibility of determining the most
economic interval for periodic testing.
Consider a simple line diagram as shown in Figure A3 below.

A B
P1 P3
E
Z4<
P2 Z3<
C
Z1< Z2<
Figure A3: Single Line Diagram

If a fault occurs on the line C-D, Relays Z1 and Z2 should clear the fault at Stations C and D. Consider
a failure to operate in Relay Z1. Relays Z4 and Z3 will then clear the fault current from C to the fault,
assuming no infeed from the transformer in C. This Remote Back Up is the normal course of action
when redundant protection is not implemented.
The Remote Back Up action will often result in an interruption of power delivery to customers. This
can cause a customer considerable costs due to increased production needs and loss of income. The
utility might be forced to pay an additional charge to the customer if there is an agreement for this.
The unwanted power delivery will cause ill will, which, in a deregulated market, might cause the utility
to lose the customer. Customers are, in general, very aware and are not willing to accept too many
power delivery interruptions caused by maloperation of the utilities protection system. Therefore, it is
important for utilities to maintain a log of these types of events.
The costs that are involved in this type of problem are the costs for testing the relay ( Ctest ) and the
costs incurred due to the interruption of power delivery ( Cint ).
The Ctest decreases as the interval between periodic tests increases. Cdisc increases at the same time.
12/26/2009 CIGRE 34.10

99
Ctest ( T )
Ctest( T )
Cdisc( T )
Cdisc( T )
BE
0 5 10 15 20 25
T
Figure A4: The Cost for Test and Unreliability as a Function of the Interval Between Periodic Tests
The point where the curves Ctest(T) and Cdisc(T) intersect is the Break Even point (BE), i.e., the point
where the total cost is lowest. The BE can be estimated by setting the derivative of the total cost, Ctot
equal to zero and solving for T as a differential equation of the total cost.
Definition of the cost for test as a function of the interval between tests:
The Ctest , as a function of the time interval between tests, T, and the time for study, t, where T < t, can be
expressed as:
t
Ctest (T ) = Ctest (22)
T
Definition of the cost of an outage as a function of the interval between tests:
The outage cost, Cint, for a utility (with a main objective to distribute energy) is based upon the
interrupted power and the interrupted energy to the customer. This can be expressed as:
C int = CP P + CE P tx (23)
where:
CP is the cost in $/MW
n
P is P1 + P 2+ ..... Pn , the loss of power (MW)
1
P1 Pn is the power for the individual stations that are affected by the outage
CE is the cost for the loss of energy ($/MWh)
tx is the time that the power has been interrupted to the consumer
However, the cost must also take into consideration the influence of the fault rate of the protection and
the fault rate on the protected line. Considering this, Cint can be expressed as:
t
C int(T ) = UA(T ) w (CP P + CE P tx) (24)
T
Using the expression given in equation (16), the mean value of the unavailability can be expressed as:
1
UAmena(T ) = 1 (1 e T ) (25)
T
Taking formula (25) into account, the total cost can then be expressed as:
12/26/2009 CIGRE 34.10
100
If equation (22) is summed with equation (24), the sum gives the result:
With reference to [1], the optimum interval for periodic tests can be evaluated by the following
formula:
Cp Pdisc + Ce Pdisc tx
= e T (26)
(Cp Pdisc + Ce Pdisc tx ) (1 + T )
The results of calculations for T of different lengths of the line and different power interruptions and
can be seen in the tables below.
Two cases with different power interruption times have been calculated: one case with an interruption
time of 15 minutes and one of 45 minutes. The customer outage cost used is 1250 US$ for the loss of
power and 3125 US$ for the loss of energy. These figures represent a mean value of different types of
consumers in Sweden. In reality, the customer outage costs differ considerably between the different
categories. The figures also differ between countries.
P Line length Line length Line length

(MW) 10 km 50 km 100 km
20 3.2 1.5 1.0
40 2.3 1.0 0.7
60 1.9 0.9 0.6
80 1.6 0.7 0.5
100 1.5 0.7 0.5
Table A4: Optimum Interval in Years for Test of Electronic Relays.
Interruption Time = 45 minutes

(MW) 10 km 50 km 100 km
20 6.1 2.7 1.9
40 4.3 1.9 1.4
60 3.5 1.6 1.1
80 3.0 1.4 1.0
100 2.7 1.2 0.9
Table A5: Optimum Interval in Years for Test of Numerical Relays.
12/26/2009 CIGRE 34.10

101

(MW) 10 km 50 km 100 km
20 4.4 2.0 1.4
40 3.1 1.4 1.0
60 2.5 1.1 0.8
80 2.2 1.0 0.7
100 2.0 0.9 0.6
Table A6: Optimum Interval in Years for Test of Electronic Relays.

(MW) 10 km 50 km 100 km
20 8.1 3.6 2.6
40 5.7 2.6 1.8
60 4.7 2.1 1.5
80 4.0 1.8 1.3
100 3.6 1.6 1.1
Table A7: Optimum Interval in Years for Test of Numerical Relays.
4.2.2 Conclusions
The calculations show that the interval between tests can be considerably shorter when justified by
economic reasons as compared to justification based on technical reasons.
Ctest 2
Use of the approximate formula: T = gives approximately a 25%
( Pdisc + Ce Pdisc t )
increase in the interval between tests.
12/26/2009 CIGRE 34.10

102
4.3 The Influence on Skills

The personnel who perform the periodic tests and the repair of relays have first-hand knowledge of
both the relay system and the relays themselves.
The new techniques of multifunction protection with built in self-supervision will probably result in
fewer occasions where maintenance personnel have the possibility to work with the protection relay.
This, in turn, might lead to a loss of skills for the maintenance personnel, since working with the
equipment is a very important way of understanding how the protection equipment works and also to
maintain employee skills
The influence on the skill level of employees when increasing todays interval of periodic tests to a less
frequent situation is important and must be considered. It is not only the loss of the opportunity for
hands-on experience with the protection, it is also the total system knowledge that may be lost. Of
course, this depends on the situation of the utility. If the company extends the periodic test interval
considerably, work with commissioning new equipment might be one way of maintaining knowledge.
However, this is not the case for most industrial countries. In practice, this might lead to the need to
not expand the periodic test interval for some protection in order to have a suitable combination of
protection types available to maintenance personnel to ensure skills are not lost.
12/26/2009 CIGRE 34.10

103
4.4 Zero Maintenance
4.4.1 Considerations on No Periodic Tests

For most applications, a change to no periodic tests will increase the cost for loss of power delivery,
because the fault will be cleared by remote protection when there is a failure to operate by the main
protection. Consider a simple application as shown in Figure A5, below, where no redundant
protection or breaker failure protection is installed at Station A. A failure of the protection to operate
at A with a fault on line A - B will normally be cleared by the protection at Station B (ordinary trip)
and a remote trip at Stations C and D.
D B
breaker
A
Figure A5: Simple Power System Network Showing Breakers with Protection
For operation personnel in the remote control centre, the fault seems to be a bus fault at Station A.
Therefore, normally Station A will be inspected before it is energised. This could take at least 45
minutes, depending on the distance from the remote control centre to the station.
With reference to section 4.1.2.1, using formulae (2) and (3) the following formula can be used to
perform the calculation of the yearly outage cost:
C int = UA(t ) w (CP P + CE P tx) (27)
It can be seen from the formula above that the interruption cost depends on many variables, such as the
interrupted power, the unavailability of the protection, and the interrupted time. The probability of
failure to operate as a function of time for relays that are not periodically tested can be seen in Figures
A6 and A7.
12/26/2009 CIGRE 34.10

104
Outage costs for Single Protection

4 .10
30033.80083 4
180.119 200 Outage Cost for Redundant Relays
3.6 .10
4
180
3.2 .10
4
160
Cinte( 20 , t ) 2.8 .10
4 1
Outage cost (US$/year)
Cinte ( 20 , t ) 140
Cintn( 20 , t ) 2.4 .104 1
Outage cost (US$)

Cintn ( 20 , t ) 120
Cinte( 60 , t ) 2 .10
4
Cinte ( 60 , t ) 100
Cintn( 60 , t ) 1.6 .104 Cintn ( 60 , t )
2 80
4 3 2
1.2 .10
4
60
8000 3 40 4
4000 20
0 0
0 0
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
0 t 20 0 t 20
Time (year) Time (year)
Figure A6: The outage cost for single relays Figure A7: The outage cost for redundant
as function of time for the outage power of relays as function of time for the outage
20 and 60 MW (=0,8) power of 20 and 60 MW (=0,8)
1= Electronic relays, outage power = 60 MW 1= Electronic relays, outage power = 60 MW
2= Numerical relays, outage power = 60 MW 2= Numerical relays, outage power = 60 MW
3= Electronic relays, outage power = 20 MW 3= Electronic relays, outage power = 20 MW
4= Numerical relays, outage power = 20 MW 4= Numerical relays, outage power = 20 MW
A numerical calculation for single relays where the CP=1250 US $/MW, P=20 MW, CE= 3125 US
$/MWh, tx=45) gives the total cost of 5006 US $/year for electromechanical relays where the line
length are 10 km. If we do the same calculations with numerical relays where the effectiveness of the
self-supervision is set to 80%, the outage cost will be 1086 US$/year.
When introducing redundant relays, the probability of having a failure to operate will be very low. If the relay
in Main1 has the same fault rate as Main 2, the probability to have a failure to operate in both relays at the same
time can be calculated as 2 , which gives a fault rate equal to 3.334 10 5 and 8.218 10 5 , respectively. In this
case, the outage cost will drop to 30 and 15 US$ per year, respectively, for electromechanical and numerical
relays, respectively. The results of the numerical calculations can be seen in Tables A9 and A10, below, where a
20-year period is included in the calculations.
Observe that the calculations have been performed using the unavailability for failure to operate. If instead the
fault rate for incorrect operations is used, the outage cost will be approximately twice as much as noted in Tables
A8 and A9 due to the fault rate being approximately twice the fault rate for a failure to operate.
Single Relays
Outage Power Electromechanical Relays Numerical Relays, =80%
Outage Costs in US$ Outage Costs in US$
12/26/2009 CIGRE 34.10
105
(MW) 10 km 50 km 100 km 10 km 50 km 100 km

20 5006 25028 50056 1086 5432 10865
40 10011 50056 100113 2173 10865 21730
60 15017 75084 150169 3259 16297 32595
80 20022 100113 200225 4346 21730 43459
100 25028 125141 250282 5432 27162 54324
Table A8: The outage cost at different interruption power and line lengths for single electromechanical
and numerical relays with an interruption time of 45 minutes
Redundant Relays
Outage Power Electromechanical Relays Numerical Relays, =80%
Outage Costs in US$ Outage Costs in US$
(MW) 10 km 50 km 100 km 10 km 50 km 100 km
20 30 150 300 15 74 148
40 60 300 600 30 148 296
60 90 450 900 44 221 444
80 120 600 1200 59 296 592
100 150 750 1500 74 370 740
Table A9: The outage cost at different interruption power and line lengths for redundant
electromechanical and numerical relays with an interruption time of 45 minutes
It can be seen in Table A8, the outage cost will soon be quite high, however, it is difficult to tell where the limits
are. This depends to a great extent on specific local circumstances.
In the case of redundant relays, the influence of the self-supervision will have an affect on the protection relay
that will decrease the fault rate and thereby decrease the outage cost. Normally, redundant relays are mostly
installed on systems with voltages of 220 kV or higher. Installing redundant protection on these systems is
mostly due to stability problems that are associated with very high outage costs.
12/26/2009 CIGRE 34.10

106
4.5 Condition-based Maintenance
4.5.1 Introduction
Historically, the interval, as well as the relay maintenance programme, was not often guided by strict
rules. The opinion of the maintenance engineers has always been an important factor in determining
the necessity of maintenance on a relay.
If the factors are analysed that determined the maintenance engineer's opinion on how and when to test
a specific protection, some of the following factors would be found:
The availability of personnel to do the maintenance
The opportunity to perform the maintenance, e.g. in parallel with HV-equipment maintenance
The experience with a certain type of relay: Is it reliable? Is it well supervised?
The manufacturers recommendations
The importance of the application: Are important customers or sensitive loads disconnected during a
maloperation (security)? Can we permit delayed elimination (dependability)?
The redundancy in the protection scheme: Is there more than one main protection (dependability)?
The number of relay operations in service per year: It may not make sense to test a relay every 2
years when it operates only several times per year.
Condition-based maintenance is, in fact, no more than a formalising the opinion of the maintenance
engineer. Several condition factors are assembled to determine, by function, the specific rules of
whether a test is necessary of a certain protection at a particular time and what needs to be done. This
is not a single factor evaluation, as most of the previous ones discussed. The interval will probably not
be constant since the above factors can change over the life of the protection. The development of such
a model should consider the following specific parts:
A Rules
B
C
Condition D ... Actions
parameters
...
Figure A8: Condition-based Maintenance Model
What are the condition parameters on which we base our maintenance?

What are the rules for determining the influence of the different condition parameters?
What are the time specific actions we derive as a result of the rules?
12/26/2009 CIGRE 34.10

107
The maintenance actions themselves are condition parameters for the Condition-based Maintenance
Model.
The advantage of this model is that it can take into account all the single influence parameters that have
been discussed previously in this section. This leads to a more balanced overall result. The
disadvantage is that the determination of the periodic programme could depend on many input
conditions. This makes it cumbersome to set up and that the rules used could be complex and open to
discussion.
4.5.2 The Condition-based Parameters

Different condition parameters will be discussed later. But before this discussion, some criticism is
made on the use of these parameters and cannot be generalised. Every user needs to make a careful
evaluation of the relevance of these parameters to their specific case by examining the following:
The use of a parameter should not imply more work than it avoids. In other words, generally the
parameter should exist or be readily available, preferably in a database.
The parameter should be reliable. For example, if the depth of self-supervision is considered as a
condition parameter to reduce testing on numerical protection, which is of course the goal, then
reliable information about this depth needs to be available.
The parameter should be clear and usable on the result. This should be evaluated together with the
rules. Consider the following rule: If (5A+1B+0.0001C) > 0, then Action 1 = True. If A, B, C
are of the same order of magnitude, it is clear that parameter C might well be neglected.
The following figure shows different condition-based parameters.
Periodic test Rules

Protection Data
Application conditions
Experience
Faults
Figure A9: Condition-based Parameters
A more detailed analysis of these different condition parameters follows.
Periodic Test
This is partially a feedback loop in the system. When the Condition-based Maintenance System leads
to an action, the action should be reset after it is executed.
Information to be noted might be:

12/26/2009 CIGRE 34.10
108
Date of maintenance
Were all prescribed actions executed?
What were the results? Did the relay respond as expected? Note that this item should not
necessarily be introduced directly, but could be introduced via the protection data (see below).
For a specific protection the same data for the parallel protection could also be considered. It would be
possible to delay the periodic test of one protection if the redundant one has just been tested.
Other periodic test information (which is not feedback) that could be taken into account is:
Personnel availability
Test opportunities (HV-equipment test planning - customer test planning)
Regulations
Generally, all this information will be collected from the operation units.
Protection Data
This condition considers the basic performance specifications of the relay. These are static parameters
that normally do not change over the life of the relay. Different aspects could influence the test
programme, such as:
The technology of the relay as a general parameter
The concept itself, e.g. the number of independent measuring systems
The reliability of the relay (as described in the Technological Conformance Tests)
The depth and quality of the self-supervision (also described in the Technological Conformance
Tests)
The manufacturers advice, whether it be general or specific (e.g. replacement of capacitors)
The reliability influence could be introduced via the result of the methods developed in appendix 4.1.
The methods are based on reliability analysis.
Throughout this entire paper, it has been highlighted how important self-supervision is in the
determination of a periodic test programme. Section 2.4 explains in detail how self-checking features
should be analysed. The block division approach permits the definition of block specific actions in the
Condition-based Maintenance Model. However, it is generally expected that the protection
manufacturer gives the necessary information for these aspects.
Application Conditions
Specific application conditions can also be considered when performing an evaluation of the necessity
of periodic testing. Some are mandatory. The application influence can be divided into the influence of
the importance of the application and the influence of the application scheme. Concerning the
importance of the application itself, the following factors can be considered:
The risk to the customer or the importance of the customer (type of contract)
The influence of maloperation on the stability of the network
12/26/2009 CIGRE 34.10

109
The acceptability and capability of back-up fault clearing (regulations)

The probability of faults
The regulations concerning periodic tests
Most of these factors are closely linked to economic considerations. The model developed in section
4.2 could therefore provide very helpful input.
Concerning the protection scheme itself, the following factors have some influence:
The number of main protections
Is the use of the protection complex? (adaptive features, etc.)
The redundancy in other parts of the scheme (supply, CTs, VTs, wiring, breaker coils)
The use of the self-supervision alarm and its redundancy
The last item is an implicit condition when basing the interval on the existence of self-supervision.
The use of self-supervision should therefore be confirmed.
Planning and co-ordination departments should normally give the information relating to this
parameter.
Experience
Experience is a dynamic parameter and changes over the life of the protection. Bad experiences will
generally increase the need for periodic testing while good experiences will decrease it. The
experience parameter can be divided into two parts:
1. Experience on a type of protection
2. Experience on a specific protection
Experience on a type of protection will lead to an extrapolation of this experience on the complete
family. The periodic testing philosophy should be adapted for the whole family. This type of
influence will therefore generally be linked with the protection data previously described.
A basic experience factor could be established on the basis of relay type testing results or, eventually,
on international experience. Afterwards, the experience factor should increase over the years until a
bad experience will, inevitably, occur.
Experience with a specific protection will lead to actions on that specific protection. Consequently,
this type of action is related to the application conditions previously described.
Specific information will come from the utilities' operating units. General information will come from
the utilities' centralised supervision staff.
Fault
12/26/2009 CIGRE 34.10

110
Each relay operation in service could be considered as a partial test of the scheme. Therefore, it seems
logical to make the periodic test programme dependent on the occurrence of a fault. Several types of
protection functions can be considered:
Basic functions, generally fast tripping with opening of the breaker
Back-up functions, generally delayed tripping with opening of the breaker
Back-up start, generally starting of the relay without breaker action
These functions lead to a different influence on the necessity for periodic tests. But the influence will
never be 100%, since the complete scheme is not activated. For example, in the case of a phase to
earth fault in a single-phase trip scheme, the two unfaulted phases are not completely tested.
Therefore, the influence should preferably be statistically evaluated on the basis of several operations
of a protection. Information on this will come from the fault analysis department.
4.5.3 The Actions

Several actions can be defined that are to be taken on a specific relay. These actions can be linked with
time information, i.e. when the maintenance should be performed, or entered on a priority list.
The details of this list depend on the utility's organisation. One can opt for basic generic actions to be
taken, e.g. verification of the protection or a total verification of the scheme. But it is also possible to
foresee very specific and detailed actions such as change capacitor C2. Some examples of actions
are given in Table A10.
Beside the actions, the system itself can also provide some warnings such as not enough personnel to
perform the job or urgent action X from 3 months ago is still active.
4.5.4 The Rules

It should be clear from the discussion on conditions that determination of the rules is not necessarily
easy and is partially subjective. There are mainly two problems:
1. Defining the rules for each condition parameter
2. Weighing the different rules against each other
The rules for each condition parameter define the action related to the specific condition parameter. If
it concerns specific action, the rule will generally be simple. For generic actions or influence on
interval, the rule will be subjective:
How many real faults are needed before performing an injection test?
What is the relationship between self-supervision depth and periodic test intervals?
What interval multiplier should be applied considering the risks related to the application?
Weighing the different parameters is even more subjective and difficult:
Is the reliability consideration more important than cost considerations? (section 4.1 compared to
4.2)
Should redundant protection schemes without self-supervision be tested more frequently than a
single protection scheme with self-supervision?
12/26/2009 CIGRE 34.10

111
Does the number of real faults on a network effectively decrease the test interval due to its in-built
testing capacity or does the number of real faults effectively increase the test interval due to the
increased importance of reliability in these cases?
Some examples are given below:
Condition (X = Specific Relay) Action

If (X = Type A) and (Last Capacitor Verification (X) = 10 years ago) Verify Capacitor on Specific
Relay
If (Nr Base Fault clearings over 2 years (X)>5) and Reset Injection Test Interval
(Experience (X) = Good)
If (Self-supervision Alarm Redundancy = False) Test Self-supervision Alarm
Every 2years
Table A10: Examples of Rules and Actions
Given the number of uncertainties, the complex decisions to be made and the amount of conditions, it
is clear that Artificial Intelligence (AI) methods are well apapted as implementation tools for
Condition-based Maintenance Systems. Some of the AI-methods include: expert systems, fuzzy logic,
model base reasoning, neural networks.
4.5.5 Conclusion
Condition-based Maintenance is an intuitive method to determine the interval and the programme of
periodic testing. It is not based on one parameter, but on different condition parameters, from which
some may be analytical and others may be instinctive. All these parameters influence the action to be
taken at a given moment.
The system will be able to provide condition-based action instead of one based solely on a set interval.
The methods of previous chapters always focus only on determining the interval. These are the main
advantages of the Condition-based Maintenance Model.
The disadvantage of the system is that it depends on a substantial amount of information, both static
and dynamic. Therefore, the evaluation method itself could be rather complex and severe. To make
this approach worthwhile, some basic conditions should be fulfilled:
Easy availability of the inputs (parameters) preferably in a database
Keep the model as simple as possible
Determine clear and workable action
Due to the specifics of the management of a network, it is not believed that one Condition-based
Maintenance Model can apply to all utilities.
12/26/2009 CIGRE 34.10

112
5. References
12/26/2009 CIGRE 34.10

113
Ref. 1: Evaluation of characteristics and performance of Power System Protection Relays and Protective
Systems, M. Monseu et Al., Cigr WG34-04 January 1986
Ref. 2: Survey of the testing of network protection devices and the differences in the tests between
electromechanical and digital equipment, Reinhard Fuchs - KEMA-IEV Gmbh, Doble, Protection apparatus test
- 1995
Ref. 3: Predicted Availability, Reliability and Maintainability of Static Protection Equipment, IEC TC95
Committee Draft
Ref. 4: Proposed Statistical Performance measures for microprocessor-based Transmission-line protective

relays -Part 1 - Explanation of the statistics & Part 2 - Collection and uses of data, Udren et Al, IEEE WG D5
- 1996
Ref. 5: End-to-End Testing for Routine Maintenance, Cliff Tienken, Jay Gosalia, A.T. Giuliante, 1997 Annual
Western Protective Relay Conference - Oct. 1997
Ref. 6: Re-engineering, Relay Engineering, A.T. Giuliante, 1997 Annual Western Protective Relay Conference
- Oct. 1997
Ref. 7: A New Philosophy for Protection Diagnostics, James A Jodice, T. Giuliante - Doble, Protection
apparatus test - 1996
Ref. 8: Results of GPS Satellite Synchronized end-to-end Transient simulation and dynamic state tests on
500kV and 750kV Circuits, J. A. Jodice et Al - Cigr colloquium SC34 Stockholm, June 1995
Ref. 9: Transformer Inrush: Testing second harmonic restraint using transient test equipment, Scott G Helbing
- Doble, Protection apparatus test, 1994
Ref. 10: Use of satellite timing signals in scheme testing on transmission line protection including recent field
experience, Robert Ryan - Doble, Protection apparatus test, 1993
Ref. 11: Relay performance evaluation using fault simulation and end-to-end testing: collected experiences,
Robert Ryan - Doble, Protection apparatus test, 1992
Ref. 12: Replaying D.F.R. Records, J.A. Jodice - Doble
Ref. 13: Use of equipment built-in automatic testing, selfchecking and monitoring with a view to improving
reliability, J. Gartner et Al. - Cigr SC34 - 1986
Ref. 14: Test Recommendations for Self-monitored Protection Relays, VDEW Working committee Relays and
Protection equipment - April 1995
Ref. 15: Self-monitoring techniques, Bertil Lundqvist - ABB 1MDL0600-EN - Octobre 1996
Ref. 16: Adaptive Protection, A. Phadke et Al., SC34-WG2 report, 1996
Ref. 17: Relay Performance Testing, J.A. Jodice, IEEE 96SM 527-2 PWRD - 1996
Ref. 18: Recommendations for a philosophy concerning software changes in digital Protections, F. Wellens et
Al., Cigr SC34 Journal n4 - 1993
Ref. 19: Detection of faults on protection systems by L Lohage Swedish State Power Board and G Axelsson
Sydkraft, Paris Session 1984
12/26/2009 CIGRE 34.10

114
Ref. 20: Electric Power Transmission System Engineering, Analysis and Design by Turan Gnen, ISBN 0-471-
85993-1.
Ref. 21: Experience in the application of databases to improvement of protection systems by T Matsuda Tokyo
Electric Power Company and others, Cigre Colloquium Johannesburg 1997.
Ref. 22: Inventarisatie van foutoorzaken en te treffen tegenmaatregelen ten behoeve van de bedrijfszekerheid
KEMA report 43731-T&D 94-108348 December 1994
Ref. 23: De invloed van toestandsbepalende functies op de beschikbaarheid van, en het onderhoud aan
digitale beveiligingsrelais KEMA report 94460370-TDP 98-102341 May 1998
Ref. 24: Grundlegende Sicherheitsbetrachtungen fr MSR-Schutzeinrichtungen draft standard DIN V 19250

May 1994
Ref. 25: Grundsatze fr Rechner in Systemen mit Sicherheitsaufgaben draft standard DIN VDE 0801 January
1990
Ref. 26: ARM, TC95 (second dot): 95/51/CD March 1997
Ref. 27: IEC 60255 series - product standards for electrical relays
Ref. 28: IEC 61000-4 series- standards for electromagnetic compatibility, testing and measurement
Ref. 29: CISPR 11 - limits and methods of measurement of radio disturbance characteristics of industrial,
scientific and medical (ISM) radio-frequency equipment 1996
Ref. 30: CISPR 14 - limits and methods of measurement of radio disturbance characteristics of electrical motor-
operated and thermal appliances for household and similar purposes, electric tools and electric apparatus,
January 1993
Ref. 31: ENV 50204 - radiated electromagnetic field from digital radio telephones, immunity test, March 1995
Ref. 32: IEC 60694 - common specifications for high-voltage switchgear and controlgear standards, May 1996
________________________
12/26/2009 CIGRE 34.10

115
Test Classification for Numerical Protection Scheme Testing
Type Tests
Test Importance for
Certification Application
Conformance Tests
Functional Conformance Tests: Mandatory Some verification
- verifying characteristics against specifications points
- verifying performance against specifications
Technological Conformance Tests: Mandatory Some verification
- verifying hardware quality (insulation, climatic, EMC, etc.) against points
specifications
- reliability assessment (ARM: Availability, Reliability,
Maintainability) against specifications
- quality/depth of self-supervision against specifications
Performance Tests
Function Performance Tests: Important Important
- testing functions separately on all functions on used functions
Scheme Performance Tests: At least one Very important in
tests under realistic operating conditions with the relay configured as it sample specific cases
will be applied, either an actual or theoretical scheme
Upgrade Type Tests: Important Some verification
- verifying the modified parts points
- verifying global consistency
Individual Tests
Acceptance Tests (could be included in commissioning):
- verification of delivery (the product received complies with the one tested)
- verification of health of protection
- verification of proper software implementation (manufacturers verification procedure)
Commissioning Tests
(Normal) Commissioning Tests
- verification of all inputs/outputs and alarms
- verification of application conformance
- verification of scheme response
- parts of standard commissioning tests: depends on whether an upgrade has been made
Periodic Tests
- verification of scheme performance
12/26/2009 CIGRE 34.10

116

Cigre 764

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cigre 764

Uploaded by

Copyright:

Available Formats

34 Analysis And Guidelines For Testing Numerical Protection Schemes

Analysis and Guidelines

12/26/2009 CIGRE 34.10

Jos Manuel Gallastegi (Spain)

12/26/2009 CIGRE 34.10

2.4.5 Contents and Interval of the Maintenance Work ________________________________ 44

3.5.1 Introduction ____________________________________________________________ 77

12/26/2009 CIGRE 34.10

Intentional Blank Page

12/26/2009 CIGRE 34.10

12/26/2009 CIGRE 34.10

1.1 Considered Tests and Vocabulary

1.1.1 Test Classification For Numerical Protection Scheme Testing

Functional Conformance Tests

Technological Conformance Tests

12/26/2009 CIGRE 34.10

Function Performance Tests

Scheme Performance Tests

Upgrade Type Tests

Normal Commissioning Tests

Upgrade Commissioning Tests

1.1.2 Certification versus Application Tests

12/26/2009 CIGRE 34.10

12/26/2009 CIGRE 34.10

1.2 About the Content

12/26/2009 CIGRE 34.10

12/26/2009 CIGRE 34.10

12/26/2009 CIGRE 34.10

2. Analysis of Specific Items in Numerical Protection Influencing Testing

12/26/2009 CIGRE 34.10

2.1 Data Acquisition and Processing

Analogue A/D M D Processor 1 O

12/26/2009 CIGRE 34.10

Concerning the system hardware, the following characteristics are of importance:

Some of these points will be considered later.

2.1.2 Long Term Stability of Components and Programmes

2.1.3 Sensitivity to Disturbances

The consequence of a disturbance on a numerical system could be a permanent destruction (often

2.1.4 Standardised Hardware

2.1.5 Filters and A/D Conversion

12/26/2009 CIGRE 34.10

2.1.6 Digital VT / CT Inputs

2.1.7 Validating the Algorithmic Process

12/26/2009 CIGRE 34.10

The questions concerning validation of the process include the following:

2.1.8 Reproducibility of the Process

12/26/2009 CIGRE 34.10

2.1.9 Link Between Function and Component

2.1.10 Availability of Values

12/26/2009 CIGRE 34.10

2.1.11 Minimum Requirements on the Protection for Testing

Requirements Reasons Type of Testing

2.1.12 Demands on the Test/Evaluation Equipment

12/26/2009 CIGRE 34.10

2.2 Programmable Input/Output Logic

Figure 2: Input-Output System

Figure 3: Input/Output Masking or Marshalling

12/26/2009 CIGRE 34.10

2.2.2 Logic Circuit Complexity

2.2.3 Single Input versus Multiple Input Energisation

2.2.4 Minimum Sense Time and Pickup Value of Inputs

12/26/2009 CIGRE 34.10

2.2.5 Hysteresis of Inputs