Testing of Substation Control and Automation Systems

IEC 61850 was issued as an international standard in the early years of the 21st century and has been recognized as the benchmark for Substation Automation System (SAS) projects. Version 2 and the 2.1 revisions are widely accepted worldwide. Since protection functions are also implemented, it is necessary to perform testing. Protection devices are periodically tested to verify their functions as well as their setting groups. This cannot be carried out in the traditional way within SAS and SCADA systems. This article highlights the importance of this topic.

Concepts in the standard

Data Model and Test Mode: According to IEC 61850-7-4, every IED includes a data model composed of Logical Nodes (LN). The LNs are arranged within Logical Devices (LD). The LNs contain information such as protection operation or circuit breaker positions. In addition, each LN contains a “mode” attribute (Mod).

There are five different modes: ON; Blocked; Test; Test/blocked; OFF.

Considering the comprehensive setting configurations of an LD results in a behavioral state (Behavior – Beh). Annex A2 contains a table describing the complex dependencies.

Simulation Indication: In Edition 2, with GOOSE messages and Sampled Values, a new information attribute was introduced to differentiate between real messages and simulated ones. The simulation indication “S-indication” is applied across the entire physical device (LN LPHD – Physical Device), and its application can be compared to traditional test switches.

CILO Interlocking: Logical Node classes that begin with the letter “C” indicate control-related applications. Therefore, “CILO” specifies whether interlocking conditions are fulfilled and whether the control of a device is permitted. Every switching device has such a Logical Node. The position status needs to be subscribed. Performing interlocking is solely an internal (local) issue within this LN.

Monitoring with LGOS: IEC 61850-7-4 specifies LGOS as a Logical Node. The first letter (L) indicates a system-level characteristic of this LN. Introduced in Edition 2, this Logical Node allows monitoring of GOOSE message subscription.

Life Cycle of an SAS project.

The standard does not describe the testing of SAS; instead, it describes the life cycle of a project (Section 4). Typically, the stages include FAT (Factory Acceptance Test) and SAT (Site Acceptance Test). Considering the entire life cycle, Figure 1 illustrates the entire project—from the specification phase to working with the actual equipment. The project begins at the desk when specifying the technical requirements and using them for tender documentation. Section 6 of IEC 61850 describes the configuration of SAS. In addition, parameters that fall outside the scope of IEC 61850, such as relay protection settings, must be declared using the vendor-specific tools. This stage concludes with FAT and further testing, ending with SAT. However, even after SAT is completed, system maintenance must continue, and cybersecurity updates are becoming increasingly important.

SAS Testing

Interlocking:
Implementing interlocking in IEC 61850 is one of the first application areas of IEC 61850 GOOSE. The multicast mechanism allows GOOSE to easily transmit position status information—for example, the status of disconnectors—to other bay controllers or to centralized interlocking IEDs.

Different interlocking implementation methods are discussed among utilities. Each interlocking method—whether centralized or decentralized—has its own advantages and disadvantages.

When implementing these methods, the topic of testing becomes important. Working groups within utilities in the Federal Republic of Germany discussed test methods and procedures and subsequently brought this topic into international standardization. Figure 3 illustrates the relevant elements involved.

The test scenario can be carried out as shown in Figure 2.

One out of n:
Another typical example is verifying the “one-out-of-n” selection. This prevents control commands from being executed when other commands are already in progress.

Testing Methods

The previously mentioned methods are now being expanded. Simulation of IEDs continues to play an important role during the design phase, FAT, SAT, and commissioning tests. The use of an automated test set is recommended. This approach extends testing from individual IED tests and simulations to comprehensive testing of the entire SAS. The need for simulation exists throughout all project phases. Conversely, the level of application gradually decreases, and different types of tests are applied (see Figure 1).

Testing Solution

Overview:
The recommended testing solution includes both software and hardware components. The use of dedicated hardware—rather than merely developing a PC-based application—is preferred for the following reasons:

• Ensures cybersecurity and secure connectivity to the substation network.

• Real-time processing capability for GOOSE and Sampled Values messages.

• Supports multi-IP simulation.

• Ability to connect to multiple networks.

• Supports cybersecurity patch updates.

• Flexible and convenient licensing options.

The software provides a toolbox for various tasks (see Figure 4).

System Under Test:
As mentioned earlier, the entire system will now be tested.

Zero Line (Ignoring Primary Single-Line Wiring):
The entire system will be visualized (Figure 6). The information available in the SCD file will be used. This includes station-related data (voltage levels, bays, etc.). The standard defines the capability to model substation components using a single-line diagram.

Most SCD files currently in use do not contain this type of information. Therefore, it is recommended to work using the “zero line” approach to display the equipment (Figure 6). Zero line means grouping according to voltage levels, arranging the bays, and assigning the corresponding equipment.

Visualization within a large-scale SAS can be performed using the system map (Figure 7).

Click “Go-live” to observe the current status of the equipment.

Tracing and Monitoring Signals:
The function of an SAS is to transmit messages from the source to the destination. If an error occurs during transmission, test engineers need to trace signals along the communication paths within the SAS.

Identifying faulty signals in traditional (copper-wired) systems is very time-consuming, and with IEC 61850, this is nearly impossible to perform manually. The testing solution described here enables observation of the signal paths within the SAS, as shown in Figure 8.

The architecture used allows tracing of transmitted signals such as GOOSE messages or Reports, making it considerably easier to analyze communication issues.

On the software, the signal-based relationships can be visualized. Bay controllers communicate with the SCADA system (Figure 9).

The massive amount of information can easily cause confusion; therefore, the filtering function can support this (Figure 10) for both GOOSE messages and Reports (Figure 11).

Names:
Names in the data model. Users who are not familiar with IEC 61850 usually expect more descriptive information. The software recognizes the names, identifies their purpose, and displays them accordingly. The names can be modified (Figure 12)—for example, into the user’s preferred language.

IEC 61850 with Basic Background Information:
IEC 61850 can be visualized through DataSets (Figure 13) and GOOSE Control Blocks (Figure 14).

Analysis and Troubleshooting:
The data models of modern IEDs can be very large. Automatic grouping and filtering tools greatly assist in managing them. The most important status information will be displayed. The software analyzes the values and highlights the relevant information (Figure 15).

Sample Test Plans:
The tests are recorded as test reports and can be reused in different project stages. Figure 16 shows a predefined test plan that can be reused at another stage of the SAS project.

Following the sequence, the tests can be executed and evaluated automatically.

Testing of Logic:
Logic is used in operational interlocking, as previously mentioned, as well as in other automatic functions within the substation. Logical conditions are implemented inside the control devices. Testing these interlocking functions is an essential part of FAT and SAT.

In interlocking scenarios, the simulated or actual status of switching devices is taken into account and evaluated. To represent the results of interlocking logic conditions, IEC 61850 displays the “condition fulfilled” status in the CILO logical node.

As described in Figure 17, the proposed solution reads the values from the data model and evaluates the interlocking response by automatically reading the CILO values.

It is essential to understand that the logic response can be tested at any stage in the life cycle of an SAS project.

Therefore, even when an IED is replaced or firmware is upgraded, the entire set of previously executed tests can be repeated. Any issues identified can be addressed, and the tests can then be executed again (“test–fix–repeat”).

Note: Non-existent devices can be simulated; therefore, this method enables testing at any stage (Figure 17).

Testing After Firmware Upgrades:
In the past, commissioning an SAS meant that the system had undergone comprehensive FAT and SAT testing, but it was not periodically re-tested, and firmware was kept frozen for 10 to 20 years. Today, this is no longer the case.

IEDs in substations must also receive cybersecurity patch updates. The challenge is that afterward, everything in that relay needs to be re-tested, including all communication-related functions. At present, no standardized method exists for re-testing communication. Everything must be done manually.

The solution presented here enables automated testing and evaluation. The entire communication portion of the devices can be easily re-tested after a firmware update by running the test plans already prepared for that device (Figure 18).

GOOSE Monitoring:
As shown in Figure 13, GOOSE messages are transmitted as multicast—one device sends to multiple recipients. Therefore, every IED that is part of the multicast subscriber list will receive this information.

Receiving and using this information is called subscription. But how can we determine whether the subscribed functions are performed successfully? Of course, testing the system’s reaction will reveal this, although it often requires significant effort.

Conversely, using information directly from the IED’s data model is much easier. As noted earlier, IEC 61850 defines the LGOS logical node.

Being a system-level logical node, its data attributes describe the status of GOOSE subscriptions. Increasingly, manufacturers are providing this information. If subscription fails, it will be indicated accordingly.

Simulations

As mentioned, simulation is essential at any stage of an SAS project. Although the amount of simulation may decrease, it remains necessary throughout all phases. Starting with specifications and during configuration means there are no physical devices available. This method allows simulating any missing device. At the initial steps, this effectively means simulating everything.

Simulating IEDs involved in communication allows verification of communication paths, DataSet configurations, and data models. It is common that the local HMI (client) is not available when configuring IED settings. Simulating the SCADA system provides confidence that the IEDs are correctly configured.

During commissioning, some IEDs may not yet be available and need to be simulated. SCADA testing toward higher-level systems (control center, national control center) is a key step before putting the system into operation.

These so-called “bit-tests” are typically very time-consuming and require careful coordination between personnel at the control center.

Any problems that arise increase the risk of tests being stopped and repeated. Therefore, simulating clients is very helpful in avoiding such unwanted situations.

On the other hand, once completed, the tests can easily be repeated and save time.

Future Outlook

There are many opportunities to extend this method. Since injecting analog signals is required at least once during the testing process, this may be a future enhancement.

In modern digital substations, real-time capable hardware must generate signals in the form of Sampled Values according to IEC 61850-9-2 and IEC 61869-9.

In the past decade, the domains of control, automation, and protection have evolved together, and there is no longer a clear boundary between them. Modern testing methods must address this reality. Likewise, protection testing is shifting from individual device testing to system-level testing with feasible solutions.

Such approaches must be applied in combination and lead to an integrated overall testing process.

Conclusion

Control and automation functions are becoming increasingly important due to their widespread use in modern substation automation systems.

Automating these types of tests offers great potential for cost savings and improved power system reliability. Practical testing solutions are available.

Translated from PACWorld Magazine, September 2018

Trần Quang Minh
ENTEC A&T

Author Biographies

Andreas Klien received his Master of Science degree in Computer Engineering from the Vienna University of Technology. He joined OMICRON in 2005 and has been working on IEC 61850 ever since. Since 2018, he has been responsible for communication business in the power industry at OMICRON. He has extensive experience in substation communication, SCADA, and power system cybersecurity. As a member of IEC TC57 Working Group 10, he actively contributes to the development of the IEC 61850 standard.

Thomas Schossig (IEEE member) received his M.Sc. degree in Electrical Engineering from the Technical University of Ilmenau, Germany, in 1998.

He worked as a project engineer for control systems and as a protection relay team leader at VA TECH SAT (Germany) from 1998 to 2005. In 2006, Thomas joined OMICRON electronics as a Product Manager for substation communication products and solutions. Since 2018, he has been responsible for communication business in the power industry at OMICRON electronics. He has authored numerous papers on IEC 61850 and protection testing and is a member of IEC working groups related to IEC 61850.