Efficient maintenance testing in digital substations based on IEC 61850 edition 2

Abstract

Digital substations are mostly important in the future of the electric power industry which makes their testing a critical process to ensure the required reliability and security of the grid. The paper introduces the definition of a digital substation and efficient testing, as well as the requirements for isolation during testing. It later describes testing related features in IEC 61850 Edition 2 and testing methods that can be used in digital substations. Maintenance testing examples and testing tools requirements are also presented. And remote testing principles are described at the end of the paper. The proposed remote testing by controlling the test system in a remote substation from the convenience of the engineering office brings significant benefits by improving efficiency and safety, as well as reducing outage times.

Introduction

The transition of the electric power industry towards a smarter grid is characterized with significant efforts to improve the efficiency in performing all tasks and reducing the duration of outages in case of events related to the operation of multifunctional protection IEDs [1,2,3]. The wide spread implementation of IEC 61850 based substation protection and the increased interest in digital substations based on the sampled values interface with the substation process is providing an opportunity to develop and implement protection, automation and control systems that can be tested remotely.

The testing of hardwired protection and control systems requires a crew to drive to (in many cases) a remote location to perform maintenance testing [4,5,6]. Replacing the hard wired interfaces with IEC 61850 based communications interfaces allows remote access to the substation for remote testing.

The replacement of part or all of the hardwired interfaces with communication links requires the development and implementation of methods and tools that maintain the same level of security during the testing process, while at the same time take advantage of all the benefits that IEC 61850 provides.

The paper first introduces the definitions of maintenance testing and remote testing and answers the question “Why do we need remote testing?” It then describes the principle requirement for isolation of IEDs from the point of view of the maintenance testing in an energized substation - related to the testing of a specific function element, a local protection scheme or a distributed function are discussed. The specialists involved in the testing of protection, automation and control schemes are used to a physical isolation of the test object based on the use of test switches that allow on one hand to open the circuit that trips the breaker and at the same time to replace the analog signals from the secondary of the current and voltage transformers with signals coming from the test equipment.

The second half of the paper describes the features in Edition 2 of IEC 61850 that can be used for virtual isolation of components of the protection scheme.

The last part of the paper discusses the methods and tools that can be used to perform the testing based on the IEC 61850 Ed. 2 definitions and how they meet the requirements for virtual isolation from a practical point of view [7,8,9,10]. The benefits and challenges related to remote testing of IEC 61850 communications based protection, automation and control IEDs and schemes are summarized at the end of the paper.

Definitions

One of the main problems in the discussion of any subject is misunderstanding. It can be significantly reduced, or even eliminated, by clarifying the subject through a good definition.

Digital substation

An IEC 61850 based digital substation is a substation in which all interfaces between the primary equipment in the substation and the devices performing protection, automation, control, monitoring and recording are based on communications over the substation local area network using the models and services defined in the standard.

The devices that provide the analog interface with the process can be of several different types depending on the primary current and voltage sensor used:

• Stand Alone Merging Unit (SAMU) connected to the secondary of the conventional current and voltage transformers

• Embedded Merging Unit (EMU) connected to the low power interface of non-conventional current and voltage sensors (may include optical interface)

The physical devices providing a binary monitoring and control interface for circuit breakers and switches are called Switchgear Control Unit (SCU).

Some physical devices providing the interface with the substation primary equipment may include both merging unit and switchgear control functionality, plus eventually additional monitoring and recording capabilities. Such devices we call Advanced Process Interface Units (PIU). Figure 1 gives an example of advanced power transformer PIUs connected to substation local area networks (LAN).

Fig. 1

Advanced PIU interfaces

The PIUs publish analog sampled values and binary or other status information of redundant substation LANs that may have a different architecture depending on the substation topology, criticality and many other factors. The logical Station and Process buses can be integrated or separated depending on the implementation requirements and philosophy.

The sampled values communications can be based on IEC 61850 9-2 LE [11] or the recently published IEC 61869-9 [12] standards.

The PIUs also execute commands to operate the breakers or switches. They also subscribe to GOOSE messages from the protection, automation and control IEDs in order to trip or close the breakers while clearing short circuit faults or for other purposes.

Different Intelligent Electronic Devices (IED) subscribe to the sampled values and GOOSE messages in order to perform protection, automation, control, monitoring and recording functions [13,14,15].

A simplified abstract digital substation showing these interfaces is shown in Fig. 2.

Fig. 2

Simplified digital substation diagram

Effectiveness and efficiency

When we think about effectiveness and efficiency, there are many things that can be mixed, because some people think that they are more or less the same.

All of the discussions in the paper will be based on the following definitions, which are based on the research of many different definitions available on the Internet [16].

Effectiveness – the degree to which objectives are achieved, without consideration of the resources being used.

Efficiency – the extent to which a resource is used in order to effectively achieve an objective.

In the following sections of the paper we are going to analyze first what tools and methods need to be used in order to effectively test different types of protection and control devices, based on some specific examples.

After clarifying how we can make sure that the test object can be successfully tested, we are going to concentrate on how this can be achieved in the most efficient way.

Maintenance testing in case of incorrect protection system operation

One of the key requirements for correct maintenance testing is the reason for the test. Maintenance testing in general is that testing which is performed to diagnose and identify equipment problems or confirm that different actions taken to change settings, upgrade or repair the protection device or another component of the fault clearing system have been effective. The tests to be included in the maintenance test will depend on which of the listed above measures have been implemented.

Problems of the different elements of the fault clearing system can be of two main types – if the system does not operate when it has to and if it operates when it should not. These two types of problems are usually detected when the system is in service and an event occurs. The operation needs to be analyzed in order to determine the reason and take some corrective action to prevent future incorrect operation of the system.

Failure to operate

The main role of a protection relay is to detect when a fault occurs in the electric power system and to take the necessary actions to clear the fault by disconnecting the faulty equipment from the rest of the system. In some cases, such as transmission line or distribution feeder faults of temporary nature the protection system may also attempt to restore the pre-fault system topology using autoreclosing functions.

Failure to operate under fault conditions may have severe impact on the stability of the electric power system due to the increased duration of the fault caused by the operation of backup protection functions and the switching-off of healthy system components.

Undesired operation

As many system disturbances and blackouts have shown, one of their main causes have been operations of the protection system under non-fault conditions. These failures also need to be prevented since they may also have a negative impact on the stability of the electric power system and result in deterioration of the conditions and a wide area disturbance.

Maintenance testing requirements in case of incorrect operation

The maintenance testing in case of incorrect operation are of two types:

• tests used to determine the reason for the operation

• tests used to confirm that a required corrective action has been successfully implemented

Determining the reason for the incorrect operation is typically done using as a first step replay of waveform records available from the relay itself or from other recording equipment at the substation. The second method is preferred for several reasons:

• the record in the failed relay may be affected by the failure of the device itself or a component of the fault clearing system – for example instrument transformers or the wiring between them and the relay

• the sampling rate of the recording by the relay may be too low which will not correctly represent the abnormal system condition

In some cases comparison of the recording (Fig. 3) from the relay that operated incorrectly and the record from another device can indicate the reason for the operation and which component of the system has failed.

Fig. 3

Single phase to ground fault on a double circuit line with current reversal

After the reason for the incorrect operation has been determined, a corrective action is required, followed by maintenance testing to ensure that the measure has been successful. The maintenance tests in this case can be based on replay of the same files used to determine the cause of the incorrect operation, or some other tests to verify changes in settings or programmable scheme logic.

In digital substation maintenance testing the test equipment is required to publish the sampled values corresponding to the recording in the COMTRADE file.

Requirements for isolation during testing

The requirements for isolation depend mainly on what is being tested and the purpose of the test. In the case of maintenance testing isolation is required in order to avoid any undesired operation of protection IEDs caused by the execution of a test procedure in the energized substation.

The requirements for functional testing of devices and distributed functions also determine the methods for testing of both types of systems are proposed based on the following order of system components tests:

• Functional testing of individual IEDs used in the scheme

• Functional testing of distributed functions within a substation

In conventional hardwired protection devices the isolation is physical (Fig. 4) using a test switch that completely disconnects the tested device from the substation environment.

Fig. 4

Physical isolation for testing

In an IEC 61850 based digital substation the physical isolation is not possible, so it is necessary to implements the test related features defined in the standard. Which features will be used will depend on the specific test case being executed.

IEC 61850 edition 2 testing related features

In order to support the testing of IEC 61850 system components in energized substations, Edition 1 of the standard already had many different features that could be used for testing. These features included:

• The possibility to put a function or a functional element (logical nodes or logical devices) in a test mode

• The possibility to characterize a GOOSE message as a message being sent for test purpose

• The possibility to characterize a service of the control model as being sent for test purpose

• The possibility to flag any value sent from a server in the quality as a value for test purpose

However, Edition 1 was not very specific on how to use these features. As a consequence, they were not supported by all vendors since interoperability could not be guaranteed.

This has been improved with Edition 2 [7,8,9,10]. Besides more detailed specifications on how to use the existing features, additional features have been added. It also includes a new modeling concept that has a significant impact on improving the efficiency of testing. It is based on the nesting of logical devices which better corresponds to the actual functional hierarchy of multifunctional protection and control IEDs.

Figure 5 shows an example of nested overcurrent protection implemented in a PROT logical device that contains and overcurrent protection ocp logical device which contains a ground gnd and phase phs logical devices.

Fig. 5

Nested overcurrent protection object model

Test mode of a function

A logical node or a logical device can be put in test mode using the data object Mod of the LN or of LLN0. The behavior is explained in Figs. 2 and 3. A command to operate can be either initiated by a control operation or by a GOOSE message that is interpreted by the subscriber as a command. If the command is initiated with the test flag set to FALSE, it will only be executed if the function (LN or logical device) is “ON”. If the device is set to test more, it will not execute the command (Fig. 6).

Fig. 6

Command with Test = FALSE

If the command is initiated with the test flag set to TRUE, it will not be executed, if the function is “ON”. If the function is “TEST”, the command will be executed and a wired output (e.g. a trip signal to a breaker) will be generated. If the function is set to “TEST-BLOCKED”, the command will be processed; all the reactions (e.g. sending a command confirmation) will be produced, but no wired output to the process will be activated (Fig. 7). The mode “TEST-BLOCKED” is particularly useful while performing tests with a device connected to the process.

Fig. 7

Command with Test = True

The behavior of the LNs in LDgnd may be changed individually or globally by means of LLN0 of LDgnd.

Their behavior may also be changed either by means of LLN0 of LDocp or by means of LLN0 of LDPROT. For example, if the mode of the functional group LDocp is set to “Off”, it not only set the behavior of all logical nodes in LDocp to “Off” but also the behavior of all logical nodes in LD3. Switching the mode of LD1 will affect the behavior of all logical devices and logical nodes belonging to the functional group LDPROT, i.e. all logical nodes in LDPROT, LDocp, LDgnd and LDphs. This hierarchy is shown in Fig. 8 and allows a very efficient control of the behavior of logical nodes during the maintenance testing in digital substations.

Fig. 8

Mode and behavior control in nested logical device hierarchy

Simulation of messages

Another feature that has been added to Edition 2 is the possibility, to subscribe to GOOSE messages or sampled value messages from simulation or test equipment. The approach is explained in Fig. 3. GOOSE or sampled value messages have a flag indicating if the message is the original message or if it is a message produced by a simulation. On the other side, the IED has in the logical node LPHD (the logical node for the physical device or IED) a data object defining, if the IED shall receive the original GOOSE or sampled value messages or simulated ones. If the data object Sim is set to TRUE, the IED will receive for all GOOSE messages it is subscribing the ones with the simulation flag set to TRUE. If for a specific GOOSE message no simulated message exists, it will continue to receive the original message. That feature can only be activated for the whole IED, since the IED shall receive either the simulated message or the original message. Receiving both messages at the same time would create a different load situation and therefore create wrong test results.

Mirroring control information

A third feature that has been added is the mirroring of control information. This supports the possibility, to test and measure the performance of a control operation while the device is connected to the system.

A control command is applied to a controllable data object. As soon as a command has been received, the device shall activate the data attribute opRcvd. The device shall then process the command. If the command is accepted, the data attribute opOk shall be activated with the same timing (e.g. pulse length) of the wired output. The data attribute tOpOk shall be the time stamp of the wired output and opOk [7].

These data attributes are produced independently if the wired output is produced or not – the wired output shall not be produced if the function is in mode TEST-BLOCKED. They allow therefore an evaluation of the function including the performance without producing an output.

Isolating and testing a device in the system

Combining the mechanisms described in the previous sections, it is possible to test a device that is connected to the system. We will explain that with a short example.

Let’s assume we want to test the performance of a main 1 protection that receives sampled values from a merging unit. In the LN LPHD of the main 1 protection relay, the data object Sim shall be set to TRUE, the logical device for the protection function shall be set to the mode “TEST” and the logical node XCBR as interface to the circuit breaker shall be set to the mode “TEST-BLOCKED”. A test device shall send sampled values with the same identification as the ones normally received by the protection relay but with the Simulation flag set to TRUE.

The protection device will now receive the sampled values from the test device and will initiate a trip. The XCBR will receive and process that trip; however no output will be generated. The output can be verified through the data attribute XCBR.Pos.opOk and the timing can be measured through the data attribute XCBR.Pos.tOpOk.

Fig. 9

Simulation of a GOOSE message

Fig. 10

Mirroring of control information

Advanced simulation possibilities

Finally, enhanced simulation possibilities that can be used for functional testing have been added. The concept is explained in Fig. 11 [7]. As described earlier, with Edition 2, the possibility do describe references to inputs of a logical node has been added. This is done through multiple instances of data objects InRef of the CDC ORG. That data object has two data attributes providing object references: one as a reference to the object normally used as input; the other one as a reference to a data object used for testing. By activating the data attribute tstEna, the function realized in the LN shall use the data object referred to by the test reference as input instead of the data object used for normal operation.

Fig. 11

Simulated inputs

Fig. 12

Black box testing

With that feature, it is as an example possible to test a logic function like a interlocking function. Instead of taking the real position indications of the different switches as inputs, the logical node (in that case CILO), can be set to use inputs from e.g. a logical node GGIO. A test application can now easily modify the different data objects of the LN GGIO to simulate the test patterns that shall be verified. That logical node can be external (the data objects being received through GOOSE messages) or it can be implemented in the IED itself for testing support.

Note that while that method allows a detailed functional testing with individually simulated inputs, it may not necessarily be used for performance testing. Since individual inputs are switched, that may change the situation concerning the GOOSE messages to be subscribed in order to receive the new inputs and therefore, the dynamic behavior may be changed.

Service tracking

While tracking of events in the application process was already possible in Edition 1 by logging or reporting of function related data that was not the case for events in the communication.

For that purpose, the concept of service tracking has been added to Edition 2. For that purpose, a data object instance has been defined for each kind of service, which mirrors the values of the service parameters. That data object can be included in a dataset for logging or reporting.

Testing methods

In order to ensure efficient testing we need to identify the efficiency criteria, i.e. which resource should be minimized. The key parameter that we can use is the time that it takes to prepare, execute, analyze and document the results of the tests.

Functional testing methods can be divided into several categories. They are related to the complexity of the functionality of the individual devices being used in the different levels of the hierarchical system, as well as the types of distributed functions implemented in it. This requires the selection of the right testing method for the specific type of test, as well is the use of testing tools that can automate the testing process.

From this point of view the following are the more commonly used testing methods:

• Functional element testing

• Integration testing

• Function testing

• System testing

A function in this case can be considered as a sub-system with different level of complexity, for example a system monitoring (SM) function, while the system is the complete redundant protection system.

Regardless of what is being tested, the test object needs to meet the requirement for testability. This is a design characteristic which allows the status (operable, inoperable, or degrade) of a system or any of its sub-systems to be confidently determined in a timely fashion. Testability attempts to qualify those attributes of system design which facilitate detection and isolation of faults that affect system performance. From the point of view of testability a functional element in a protection system is the unit that can be tested, because it is the smallest element that can exist by itself and exchange information with its peers in the protection system.

Another consideration is the purpose of the test and needs to clarify if the tests are performed in relation to acceptance of a new product or function to be used as a system monitor or process controller (or both), the engineering and commissioning of a substation component or the complete protection system or its maintenance. From that perspective different testing methods can be implemented even in the testing of the same functional element or function.

For example the testing of a system monitoring function during the user acceptance phase may focus on the testing of the measuring element characteristic using search test methods, while during the commissioning the operating times for different system conditions be the important ones achieved through transient simulation methods.

The knowledge of the internal behavior of the test object or more specifically the logic or algorithms implemented determine how the tests are being executed. The most commonly used test methods from this point of view are:

• Black box testing

• White box testing

An important aspect that needs to be considered during the testing is the availability of redundant devices performing the different protection system functions.

The following sections discuss in more detail the different testing methods listed above.

Black box testing

Black Box Testing is a very commonly used test method where the tester views the test object as a black box. This means that we are not interested in the internal behavior and structure of the tested function. Test data are derived solely from the specifications without taking advantage of knowledge of the internal structure of the function.

Black box testing is typically used for:

• functional elements testing

• protection system factory testing

• protection system site acceptance testing

Since functional elements are defined as units that are the smallest that can exist independently and are testable, it is clear that black box testing is the only method that can be used for their testing.

The response of the test object to the stimuli can be monitored by the test system using the operation of physical outputs, communications messages or reports.

White box testing

White box testing is a method where the test system is not only concerned with the operation of the test object under the test conditions, but also views its internal behavior and structure. In the case of protection system it means that it will not only monitor the operation of the system at its function boundary, but also monitor the exchange of signals between different components of the system.

The testing strategy allows us to examine the internal structure of the test object and is useful in the case of analysis of its behavior, especially when the test failed.

In using this strategy, the test system derives test data from examination of the test object’s logic without neglecting the requirements in the specification. The goal of this test method is to achieve high test coverage through examination of the operation of different components of a complex function and the exchange of signals or messages between them under the test conditions.

This method is especially useful when we are testing distributed functions based on different logical interfaces. The observation of the behavior of the sub-functions or functional elements is achieved by through monitoring of the exchange of messages between the components of the test object.

The test scenarios however do not have to be different from the ones used under black box testing.

In IEC 61850 based systems white box testing is fairly easy to achieve based on the subscription to GOOSE messages whose data sets contain data attributes representing the status of all function elements that are used in the implementation of the tested function (for example SFM on Fig. 13).

Fig. 13

White box testing

Top-down testing

Top-down testing is a method that can be widely used for protection system, especially during site acceptance testing, when we can assume that all the components of the system have already been configured and tested.

Top-down testing can be performed using both a black box and a white box testing method.

The testing starts with the complete system, followed by function or sub-function testing and if necessary functional element testing.

In the case of factory acceptance testing, when not all components of a system or sub-system are available, it is necessary for the test system to be able to simulate their operation as expected under the test scenario conditions. In this case the test system creates the so called Stubs for functions or functional elements that are not yet available.

Each functional element is tested according to a functional element test plan, with a top-down strategy.

If we consider a protection system implementation in IEC 61850 for testing using a top-down approach, we will start with the definition of the function boundary.

The testing of the individual components of a system function might be required in the case of failure of a specific test, which is shown in Fig. 7. The function boundary for each of these tests is different and will require a different set of stimuli from the test system, as well as monitoring of the behavior of functional elements using different signals or communications messages.

Bottom-up testing

Bottom-up testing is a method that starts with lower level functions – typically with the functional elements used in the system – for example PTOC.

This method is more suitable for type testing by a manufacturer or acceptance testing by the user.

When testing complex multilevel functions or systems, driver functional elements must be created for the ones not available. The test system must be able to simulate any missing component of the system when performing for example factory acceptance testing.

There are many similarities in the test scenarios used in the bottom-up, compared to the top-down method. The main difference between the two methods is the order that the tests are performed and the number of tests required.

Maintenance testing example

In order to clarify the use of the above described methods, this section includes an example of the maintenance testing of a time overcurrent function element which is part of a distributed breaker failure protection scheme.

Each logical node shown in Fig. 14 is the equivalent of a function element FE included in the description of the testing methods in the previous section.

Fig. 14

Top-down testing of a system monitoring function

Distributed breaker failure protection scheme

Breaker failure protection is a scheme that is perfectly suitable as an example for the testing of protection schemes in digital substations due to the fact that it is distributed in nature and includes merging units (MU), protection IEDs and Switchgear Control Units (SCU) communicating over the substation LAN.

Breaker failure protection is a scheme that is typically used at the transmission level of the system due to the impact of such event on the stability of the electric power system. With the availability of built in breaker failure protection function in many multifunctional protection IEDs and the increasing requirements for decrease in the duration of distribution faults it is becoming commonly used in distribution systems in order to reduce the duration of voltage sags and improve power quality and the ride through capability of distributed energy resources.

In distribution substations using hardwired analog interfaces and GOOSE messages it can be implemented as shown in Fig. 15.

Fig. 15

Breaker failure protection (distribution network)

There are many implementation possibilities for the breaker failure protection. In the (simplified) example Figs. 15 and 16 the breaker failure protection for the circuit breakers of the distribution feeders is implemented in IED3 (transformer protection). It is initiated by the operation of the overcurrent protection element PTOC in either IED2 or IED3.

Fig. 16

Testing of PTOC1 in IED2 in a distributed breaker failure scheme implementation

Fig. 17

Virtual isolation test configuration

Fig. 18

Remote testing system

The element RBRF1 in the multifunctional transformer protection relay (IED4) is associated to all feeders. When the distribution feeder protection relay (IED2) operates, it sends a GOOSE message indicating its operation requiring the tripping of the feeder breaker to clear the fault. This includes the data attribute

PTRC1.Tr.general = TRUE

As a result from

PTOC1.Op.general = TRUE

The transformer protection relay (IED4) subscribes to this message, and when it receives the change of value of a feeder protection functional element PTRC Tr data object to True, initiates the breaker failure protection function RBRF. As soon as IED 4 receives the GOOSE message

RBRF1.Str.general = TRUE

If re-trip of the breaker protected by IED 2 is implemented, IED4 will publish a GOOSE message with

RBRF1.OpIn.general = TRUE

If the re-trip still does not result in the breaker opening, after the breaker failure time delay times out it will publish a GOOSE message with

RBRF1.OpEx.general = TRUE

Each of the above attributes in GOOSE data sets must be paired with its corresponding quality attribute, for example

RBRF1.OpEx.q

If the breaker fails to trip, the fault current will keep the level of the current above the pickup setting of the breaker failure detection element, the timer will time out and IED4 will trip the required breakers (the transformer breaker and the distribution bus sectionalizing breaker) to clear the fault as shown in Fig. 15.

The external trip of adjacent breakers is through any of the breaker controllers (SCUi) represented by IEDs 5 and 6 in the figure. They are required to clear the fault.

Maintenance testing of PTOC in a digital substation

The maintenance testing can be performed in several different ways depending on the protection testing philosophy of the utility.

Complete IED isolation

If it is to maintain the existing practice of isolating the complete device from the substation while performing the testing, we need to put the top level logical device PROT in Mod = TEST. However this does not correspond to the requirements for efficiency, because there will be no dedicated protection for the distribution feeder during the testing. In this case we need to set IED2 to

PROT.Mod = TEST

This will put the behavior of all protection and protection related logical nodes in TEST.

After that the IED2 needs to be set to

LPHD.Sim = TRUE

The test set will publish the sampled values TCTR1.AmpSv with

Simulation = TRUE

The test set will have to subscribe to the GOOSE message from IED2 containing

PTOC1.Op.general

PTOC1.Op.q

The first is used to determine the operating time for the assessment of the PTOC1 performance, while the quality attribute will be examined to determine if the Test bit is set to TRUE.

Partial IED isolation

The efficient approach is to put in test mode only the function element that we are testing, meaning that for IED2

PTOC1.Mod = TEST

By doing this the quality Test in PTOC1.Op.q will be set to TRUE, which will not result in the start of the RBRF1 during the testing.

In order to do the simulation without disabling the remaining protection functions we can take advantage of the TestRef attribute in InRef.

We need to set PTOC1 to

PTOC1.InRef.tstEna = TRUE

PTOC1.InRef.setTstRef = TestDev/TCTR1.AmpSv

In order to use this approach it is essential to verify that the IED’s communications interface can process simultaneously the sampled values from both the merging unit and the test device and make the simulated sampled values only to the test logical node – in this case PTOC1.

The test set will have to subscribe to the GOOSE message from IED2 containing

PTOC1.Op.general

PTOC1.Op.q

The first is used to determine the operating time for the assessment of the PTOC1 performance, while the quality attribute will be examined to determine if the Test bit is set to TRUE.

Testing tools requirements

It is clear from the previous sections of the paper that the testing tools need to support the requirements for all the different types of test described earlier.

There are two types of tools:

• Hardware – the different test devices that generate analog signals or communications messages as required by the application

• Software – the different software tools that are used for specific types of test, test configuration, power system conditions simulation, test assessment and documentation

To support the virtual isolation, the test devices should be configurable to operate in a “normal” operating mode, i.e. by sending messages with all test mode related data objects and attributes set to False. As described earlier, these will be all use cases when there is no need for virtual isolation.

In cases like maintenance testing or commissioning of new bay protection and control schemes in an energized substation, the test equipment should send messages with the simulation bit or test bit set to TRUE, in order to prevent undesired tripping of circuit breakers.

Remote testing requirements and benefits

IEC 61850 based digital substation allow a significant improvement in the efficiency of maintenance testing. This is the result of the availability of testing related features defined in the standard which allow the isolation of the test object and testing system from the rest of the live substation without the need for physical switching or connections of equipment in the live substation.

One of the benefits of digital substations is that all devices (PAC IEDs, substation computers and test devices) are connected to the substation communications network. If there are testing tools that are connected to the network in the substation on a permanent basis, it becomes possible to perform the tests from a remote location [16]. This can be useful in many cases:

• long distance between the substation and the base of the test staff team

• difficult terrain with bad roads

• difficult weather conditions

• requirements for reduction of outage time because of maintenance

The remote testing improves the efficiency by eliminating the need to travel to the substation to perform the testing. This leads to the significant reduction in the time spent by the testing team in relation to a specific maintenance test.

Additional savings in time are the result of eliminating the need for connecting the test equipment to the test object.

The ability to isolate only a function element that is being tested improves the efficiency of operation of the electric power system by eliminating the need for an outage during the testing.

In order to be able to perform remote testing the system needs to meet the following requirements:

• Analog and digital interfaces between the process and the protection, automation and control system are communications based (IEC 61850 sampled values and GOOSE)

• Support of virtual isolation of test objects

• Remote secured access to the substation’s test system

The test system in the remote substation includes several components:

• Test computer which runs the testing software supporting IEC 61850 Edition 2 testing features and the required functional testing tools

• Test devices performing simulation and evaluation of the results from each test

The need for locating a test computer and test devices in the substation is in order to be able to accurately measure the performance of all components of the tested scheme within the real communications architecture of the substation.

The interface to the test computer is over a private cloud and requires the use of cybersecurity technology available for remote access from the engineering station by an authorized and authenticated user.

The test engineer and technician accesses the test computer in the remote substation using a remote control tool with advanced cyber security features.

The remote access to the substation test computer needs to meet all cyber security requirements, including role based access.

Depending on the requirements for the test defined by the type of maintenance testing that needs to be performed the logical nodes, logical devices or complete IEDs are set in the required mode in order to ensure their virtual isolation.

In order to further improve cyber security it is recommended to connect the test computer and the Ethernet port of the test device used to control it to one isolated segment of the substation LAN, while the port of the test device which is used to publish the simulated messages and subscribe to the messages from the tested IEDs should be connected to the station/process bus network.

Conclusions

Edition 2 of IEC 61850 introduced many new features that further enhance the power of the standard.

There are new features that should make the life of the end user easier – assuming the features are supported by future products. They are designed to support not only automated configuration and execution of test procedures, but also remote testing for some specific test cases.

Using remote testing by controlling the test system in a remote substation from the convenience of the engineering office brings significant benefits by improving efficiency and safety, as well as reducing outage times. To achieve it, many new technologies or requirements should be further researched, the correlative testing interface software, platforms and core testing algorithms should all be improved.