Possible Applications and Limitations of Wi-Fi Communications in IEC 61850 Systems

Authors: R. Persello, Fred Steinhauser, OMICRON electronics GmbH, Austria

IEC 61850 was published as an international standard in the early 2000s and is the established norm for substation automation projects (SAS). Edition 2 and the upcoming amendment 2.1 increases the acceptance worldwide. Since protection is available, there is a recognized need for testing. Protection devices are tested regularly and demonstrate functionality as well as parameter set. There are no such traditions for SAS and SCADA. This article shows why this topic becomes important.

Definitions in the standard

Data Model and Mode Test: According to IEC 61850-7-4 every IED contains a data model with logical nodes (LN). The LNs are organized in logical devices (LD). The node contains information such as startup of protection or the position of circuit breakers. Additionally, every LN contains an attribute Mode (Mod).

There are 5 of them defined: ON; Blocked; Test; Test/blocked; OFF

Taking into account the settings of an entire LD there is a resulting Behavior (Beh). Annex A2 contains a table showing the complex dependencies.

Simulation Indication: With edition 2 for GOOSE and Sampled Values a new information was introduced allowing to distinguish between real and simulated messages. This “S-indication” (simulated) is valid for the entire physical device (LN LPHD, Physical Device), its functionality can be compared with conventional test switches.

Interlocking CILO: All classes of LNs starting with C indicate “control”. So “CILO” indicates interlocking and releases a control device once the conditions are fulfilled. There is one instance of this LN per switched device. All relevant position indications must be subscribed. Realizing the interlocking is a "local issue" only.

Supervising with LGOS: IEC 61850 7-4 defines the class LGOS as LN. The first letter (L) indicates the system character of the node. This node was introduced with edition 2 and allows supervision of GOOSE subscriptions.

Life Cycle of SAS

The standard does not describe the testing of SAS but the lifecycle of a project (part 4). Commonly used terms such as FAT - Factory Acceptance Testing and SAT - Site Acceptance Testing appear. Considering the entire cycle Figure 1 we can describe the project - from specification to working with equipment. The project starts on a desk specifying and using this for tenders. Part 6 of IEC 61850 describes the engineering of the SAS. Additionally, the non - IEC-61850 parameters such as protection settings must be defined with vendor specific tools. The phase is finalized with FAT and the commissioning follows. This ends with SAT. But even after SAT maintenance might follow and security updates become more and more important.

Testing the SAS

Interlockings: Realizing interlocking in IEC 61850 was one of the first applications of IEC 61850 GOOSE. The multicast mechanism makes it easy to transmit position indications of for instance disconnector to other feeder’s bay controllers or centralized interlocking IEDs.

Different approaches realizing interlocking have been discussed between utilities. There are advantages and disadvantages for the centralized as well as for the decentralized approach.

Realizing these approaches, the topic of testing became important. Working groups with utilities in Germany have been discussing testing approaches and sequences and brought the topic into the international standardization. Figure 3 shows the components involved.

The testing scenario could be realized as in Figure 2.

One out of n:  Another typical example is the one-out-of-n check. This avoids commands in case of other commands running.

Testing Approach

The method proposed will now be extended. Simulation of IEDs stays important during design, FAT, SAT and commissioning. An automated test set is proposed. This test extends the test from single IED testing and simulation to testing the entire SAS. The need for simulation is there in all phases of the project. Nevertheless, it is decreasing and different kinds of testing apply (see Figure 1).

The Testing Solution

Overview:  The proposed testing solution shall consist of software and hardware. To use a dedicated hardware and not just develop a PC application was chosen for the following reasons:

  • Guarantee cyber security and safe connection to substation network
  • Real time capabilities to calculate Sampled Values and GOOSE
  • Making it possible to deliver multi-IP simulation
  • Connection to several networks
  • Update possibility for security patches
  • Comfortable licensing

The software offers a toolbox for the different tasks. (see Figure 4).

System under Test:  As mentioned the entire system is under test now (Figure 5).

Zero Line:  The entire system will be visualized (Figure 6). All information available in SCD file will be used. This covers also the information in substation section (voltage level, bay, etc.). The standard defines possibilities to model the elements of a single line diagram.

Most of the current SCD files do not contain this information. So, it is the proposal to work with “zero line” to visualize the assets (Figure6). Zero line means grouping by voltage level, arranging the bays and corresponding assets.

The navigation in huge SAS can be done as in map systems. (Figure7).

Clicking “Go-live” visualizes the current status of the asset.

Tracing the Signals: The functionality of the SAS transfers the message from its source to all receivers. If there is an error in this communication, the commissioning engineers need to follow the signal on its way through the SAS.

Finding such signal errors in the case of copper wiring was very time consuming, with IEC 61850 this becomes almost impossible to be done manually. The testing solution described here allows to view how signals propagate through the SAS, see Figure 8. 

The architecture used allows to follow signals communicated as GOOSE as well as Reports. This makes trouble shooting communication problems quite easy.

The software makes it possible to visualize the links. The bay controller communicates with SCADA (Figure 9).

The huge amount of information might confuse, but filters can help (Figure 10). Doing so filters for instance to GOOSE and Reports (Figure 11).

Names: The names in the data model. Non - IEC 61850 experts and users might expect more information. The software recognizes the names, detects the purpose and visualizes accordingly. Names can be edited (Figure 12) - for instance in own language.

IEC 61850 in the Background: IEC 61850 can be visualized as well- in the example for DataSets (Figure 13) and GOOSE Control Blocks (see Figure 14).

Analysis and Trouble Shooting: Data models of modern IEDs can be huge. Tools grouping and sorting the information automatically will help. The most important status information becomes visible. The software analyzes the values and shows only relevant information (Figure 15).

Test Plans: If tests are documented and recorded they can be used in different phases. Figure 16 shows a test plan ready for re-usage at another phase of the SAS project.

Sequences can be performed and assessed automatically

Logic Testing: Logic is used in interlocking, as already described, as well as in any other substation automation function. Logic conditions are implemented in control devices. Testing such logic functions is an essential part of FAT as well as SAT.

In case of interlocking, simulated or real switchgear status is considered and evaluated. To represent the result of interlocking logic conditions, IEC 61850 represents the status of the release in the logical node CILO.

As depicted in Figure 17, the proposed solution reads the value out from the data model and assesses the interlocking behavior by reading the CILO values automatically.

It is essential to understand that the behavior of the logic shall be tested in any stage of the lifecycle of an SAS.

So, even after IED-change or firmware upgrade the entire test once performed can be repeated. Issues that occurred can be solved, and afterwards the test can be repeated (“test-fix-repeat”).

Note: Non-existing assets will be simulated, so this approach allows testing at any stage. (see Figure 17).

Test after Firmware Upgrade: Putting a SAS in operation meant in the past extensive testing during FAT and SAT, but neither routine testing nor updates of firmware (frozen) for the next 10 up to 20 years. This is not valid anymore. 

IEDs in substations also must be patched with security updates. The problem is that afterwards everything from that relay needs to be re-tested, also all communication. Until now there was no proper way to re-test the communication. Everything had to be done by hand.

The solution proposed offers automatic testing and assessment. The whole communication of the device can be easily re-tested after the firmware update by executing the test plan already prepared for that device (Figure 18).

GOOSE Supervision: As visualized in Figure 13 the GOOSE is sent out as multicast - one to many. So, every IED which is a member of this multicast will receive this information.

Taking and using this information is called “subscription”. But how do I learn that the function was subscribed and received successfully? Of course, testing the reaction of the system will show that this works.

Nevertheless, using this information just from IED’s data model would be easier. IEC 61850 defines as discussed already  the logical node LGOS.

As a system node, the data attributes describe the status of a GOOSE subscription. More and more vendors are providing this information. If the subscription fails, this can be indicated.


As mentioned already simulation is important in any stage of SAS.  As explained the amount of simulation might decrease but there is a need at any stage. Starting with specification and during engineering means no real equipment is available. The approach allows to simulate any missing equipment. For the first step this means simulating everything.

Simulating the IEDs involved in communication makes it possible to check communication links, DataSet engineering and data models. Very often the local HMI (client) is not available while setting up the IEDs. Simulating this SCADA system delivers confidence that the IEDs are configured properly.

In the commissioning phase, IEDs might be not available and need to be simulated. Testing communication to higher level SCADA (control center, national control center) is an important step while putting into operation.

Those “bit-tests” are very time consuming and require the attention of the colleague in the control center.

Any problem occurring increases the probability that the test has to be stopped and repeated. Thus, simulation of client is very helpful to avoid frustrations like this.

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


There are several possibilities extending this approach. Since analog injection is required at least once during the testing this has to be possible.

In modern digital substations, the real time capable hardware has to issue the signals as Sampled Values according to IEC 61850-9-2 and IEC 61869-9.

During the last decade protection, automation and control grow together, and there is no clear border between the different tasks. Modern testing approaches must consider this. Also, protection testing moves from single-device testing to system testing and solutions are available.

Such approaches must be used together and will deliver holistic testing procedure.


Automation and control functions become more and more important because of their wide application in modern substation automation systems.

Performing such tests automatically brings an enormous potential for cost saving and enhances the reliability of the grid. Testing solutions are available. 


Andreas Klien received the M.Sc. degree in Computer Engineering at the Vienna University of Technology. He joined OMICRON in 2005, working with IEC 61850 since then. Since 2018, Andreas is responsible for the Power Utility Communication business of OMICRON. His fields of experience are substation communication, SCADA, and power systems cyber security. As a member of the WG10 in TC57 of the IEC he is participating in the development of the IEC 61850 standard series.

Thomas Schossig (IEEE) received his master’s 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 team leader for protective relaying at VA TECH SAT in Germany from 1998 until 2005. In 2006 Thomas joined OMICRON electronics as a product manager for substation communication products. Since 2018 he is responsible for the Power Utility Communication business of OMICRON electronics. Thomas is author of several papers and a member of standardization WGs.

Power. Flexible. Easergy.
Protecting your electrical assets? today and tomorrow