Bad habit of using GGIO logical nodes
Назад к блогу

Bad habit of using GGIO logical nodes

There are quite a few people saying that GGIO is a bad thing. Having a good semantic model provided by IEC 61850, it’s pretty silly to get rid of semantics by means of GGIO. However, it happens a lot due to several reasons. We tried to investigate how relevant the problem is, and what are primary factors for that.

As an input for our analysis we have used 124 unique SCL files, including ICDs for individual IEDs as well as SCD files for complete projects. There were 316 IED instances with 57 unique IED types. Finally, these IEDs produced 219 GOOSE messages and had 836 Report control blocks configured.


The data has been carefully collected and filtered out in order to get rid of duplicates, influencing final investigation results. In order to process the data, including filtering and final analysis, we have used the core of our IEC 61850 Telegram messenger bot with additional Python-based scripts providing the required information.

We have analyzed 124 unique SCL files, including ICDs for individual IEDs as well as SCD files for complete projects.

The overall database of SCL files at the beginning of the investigation have counted over 500+ files, so careful filtering has been required in order to get rid of duplicates and different instances of the same projects. The filtering has been performed in several stages. First, md5 hash has been calculated for each file, so that files with repeating hash have been removed. Second, files have been validated against SCL-schema (depending on the determined edition, respective schema has been used), so that only valid files passed. Finally, SCL files’ header has been analyzed in order to exclude different versions of the same project. Additionally, unique IED-type filtering has been applied in order to collect the data for IED-types only.

We intentionally did not want to give preference to any kind of project, vendor or IED type, so we have made completely “blind” analysis.


There have been three areas of personal interest for us in this analysis:

  • The amount of GGIO logical nodes in the IED by IED types (i.e. not IED instances, but in a set of unique IED types).
  • The amount of GGIO logical nodes, referenced by dataset FCDAs transmitted via Reporting services.
  • The amount of GGIO logical nodes, referenced by dataset FCDAs transmitted via GOOSE messages.

Overall Logical Nodes percentage by IED type

First, we took only unique IED types from the SCL files we had (with total number of IED-types equal to 57) and analyzed the overall data model of those IEDs. We have summed up all LN class instances over all unique 57 IED types. Finally, we have divided the number for each LN class by the number of overall LN instances, having the resulting ratio, depicted by chart 1.

Chart 1 - Logical nodes precentage by IED type

We have presented the data in a way that the most popular LN classes forming the 50% share of all LN class instances are marked with their names, while other 77 LN classes met in IEDs form the “other” group. As one can see from the Chart 1, GGIO logical node is the undisputed leader with 7% ahead of the second place and over 1/5th of the total share. The second place is quite expected one – PTOC with its 14%. Next 3 LN classes, having roughly 4% share, are LPHD (which actually could be used as a reference LN, e.g. we can assume, that every Logical Device has 21/4 = 5,25 GGIO on average), MMXU, PTOV and, in the end, CSWI with 3%.

We must note, that MMXU, PTOV and CSWI LNs could probably be replaced by other LN classes in case of more IED types analyzed, as the difference within 1% cannot be interpreted as stable. However, the leader is unreachable by all means. Additionally, the situation might look even worse if we have analyzed DO-DA instances inside LNs, not the LN instances by themselves, as we know that many IED types have more than one status DO inside single GGIO instance. And this could relatively be seen from the following analysis.

Logical Node classes transmitted via Reports

The second part of our analysis was the investigation of percentage of LN classes transmitted via Reporting services. We have not particularly differentiated between buffered and unbuffered reports. There have been analyzed 836 Report control blocks, which is a rather big amount. Here we can also note that in the same SCL files (mostly SCDs are considered here) there were almost 4 times as many Report control blocks configured compared to GOOSE control blocks, which can be interpreted as rather poor usage of GOOSE communication service (i.e., for protection-related purposes) compared to reporting (i.e., for SCADA/SAS purposes). The dataset of each Report control block has been analyzed in regard to the LN classes referenced by each FCDA. I.e. 2 FCDAs containing the reference to a certain LN class gave that class total of 2 points. The final sum for each LN class has been divided by the total count for all LN classes. The results of the analysis are depicted in Chart 2.

Chart 2 - Logical node classes transmitted via Reporting service

We were really impressed: 64% of the data transmitted via Reports is represented by GGIO logical nodes.

We have been really impressed by what we had seen. We had to double check our calculation algorithms in order to avoid any errors, but there weren’t any! 64% of the data transmitted via Reports has been represented by GGIO logical nodes. This was unbelievable. We added 3 more LNs just in case… PTOC and MMXU both shared the second place with roughly 6% each and the third place has been taken by PDIS with only 2%. There were other 47 LN classes transmitted via Reports with overall share of 21% (i.e. less than 0.5% for each). Along with the fact that almost 2/3 of data transmitted to SAS is GGIO, another interesting fact is that a little more than a half of overall number of LN classes is used to transmit data to SAS (51 LN classes in reports compared to 83 in IED types).

Logical Nodes transmitted via GOOSE

Sad news: 83% of data transmitted via 219 analyzed GOOSE-messages turned out to be GGIO data.

The data transmitted with GOOSE has been analyzed in the same manner as Reports’ data with the only difference that GOOSE control blocks have been analyzed instead of Report Controls in previous case. See Chart 3 for the result.

Chart 3 - Logical nodes transmitted via GOOSE

Pretty awful, isn’t it? 83% of GGIO data transmitted over 219 GOOSE messages. What does it really mean for the customers, having this installations working? Well… this is is, it’s just as if you take all of your terminal blocks and remove 83% of labels…

Using GGIOs is equivalent to not labelling terminal blocks

It’s not even so interesting to analyze other 17%, where only one more LN has more than 5% (RBRF class). It is not surprising.

Why the hell is this happening?

While 21% of GGIOs in IEDs looks not good, it seems just excellent compared to 83% of GGIOs in GOOSE messages. But why does this happen? Who is to blame for this?

The following are just our observations based on our own experience with IEDs and analysis of other’s projects where we made consultancy. These observations do not pretend to be universal truth and hardly could be generalized, however they represent real life cases and could become a good starting point for further analysis. We’ve pointed our attention to the following cases leading to unwanted use of GGIOs:

  • The lack of knowledge by design and commissioning crews.
  • Mismatch of the applied data model with nationally accepted function application profile.
  • Drawbacks of early editions of the Standard.
  • Dramatic lack of functionality in IEDs.
  • Lack of acceptable system engineering tools.

We shall step-by-step describe those cases.

IEC 61850 profiles and knowledge

To struggle bad habit of using GGIOs IEC 61850 profiles must be defined for common PAC schemes.

There are certain established principles of protection and control schemes implementation in almost every country. To implement these schemes engineers usually rely on user-defined logics. In most cases, products of such logics are output using GGIO logical nodes. It is almost a common practice to use them. To struggle with this bad habit IEC 61850 (national) profiles must be defined for these common protection and control schemes. And engineers must understand and follow these profiles, given the implemenation support from IED vendors.

Poor IEC 61850 implementation in IEDs

It’s pretty hard to imagine that IEC 61850, mostly pushed by vendors (at least on early stages), could lack IEC 61850 implementation quality exactly by these vendors… But from time to time you face it. For example, see the quote below, inherited from PIXIT for one very popular IED:

PIXIT for one quite popular IED

As you can see this IED does not support Str attribute, i.e. if you need this attribute (e.g. for the implementation of reverse interlocking scheme), you would have to create it in user-defined logic and use GGIO to publish the signal via GOOSE.

Poor system engineering capabilities

We could have named two vendors with pretty powerful system engineering tools, accompanying their hardware implementation, but this article is not about advertising, so we won’t. This article is about problems, so we must mention that dozens of other vendors do not provide proper and usable system configuration tools, capable of handy project engineering. We are not even speaking about multivendor projects here. You can stumble on really funny cases. Being unable to engineer IEC 61850 communications properly and easily with a standard configuration tool, some smart commissioning guys decided that they could just handle all the data flow engineering with GGIOs (i.e. configure static communications between IEDs using some 40 or so GGIO signals, statically published and subscribed by IEDs) and provide real system engineering with user-defined logics only. So the communications engineering is provided only once and further modifications are made only in flexible logics editor. Brilliant! Semantics? Never heard!

Ed.1 didn’t really work

So finally we are coming to the IEC 61850 standard itself, which is not sinless either. As we all know, the BlkRef concept as well as proper definition of control blocks in input sections and etc. have been described much later than the ed. 1 had been published, while application profiles are still under development. So although most of us would like to blame vendors or engineering guys, joint liability is the better term to describe the situation.


As previous parts of this paper were long enough, we do need to outline some conclusions to settle in our minds:

  • Utilities MUST understand that they are accepting blind systems with those GGIOs, loosing half of the advantages of IEC 61850 compared to outdated communication protocols.
  • Clear application profiles shall minimize the amount of GGIOs used in projects.
  • Utilities must have means to check function implementation in accordance with the defined profile.
  • While GGIOs are used, they must be well documented and include project specific descriptions.
  • Keeping this in mind, we will take the shortest path to the worldwide IEC 61850 understanding and acceptance.