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

2.1 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 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).

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–15].

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

2.2 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.

2.3 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.

2.4 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.

2.4.2 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.

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.

4.1 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).

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.

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.

4.2 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.

4.3 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.

4.4 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.

4.5 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.

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.

4.6 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.

5.1 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.

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.

5.2 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).

5.3 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.

5.4 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.

6.1 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.

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.

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.

6.2 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.