The semantic data model!

Author:Christoph Brunner, it4power, Switzerland

One of the important features of IEC 61850, often underestimated in its value, is the detailed semantic data model defined in part 7-4 with the logical nodes and hundreds of data objects that allow modeling the various application information from substation automation, protection, control and measurement including process equipment. While in a traditional SCADA system, an engineer needs to know which data point number is associated to the position of breaker 921, with IEC 61850, this information is always found as data object "Pos" of the LN XCBR. And among the multiple LN instances of XCBR in the substation, through the substation configuration language it is possible to identify, which instance is associated with breaker 921. This not only makes engineering much easier, but also facilitates maintenance.
Unfortunately in the real world, the level of implementation of these data models is not always as it should be - so maybe that is why many do not yet recognize its value.

What are the issues?

  • First of all, there is the LN GGIO. Originally intended as a place where generic information like a door contact or a fire alarm can be displayed, it has widely been misused as an excuse for better knowledge by developers of IEDs
  • Second, there is the flexibility of the standard with the logical nodes that sometimes allows multiple ways to model the same application

An example for the flexibility is the modeling of a distance protection function with e.g. three zones. It can be modeled with three instances of PDIS - one per zone. Or with 6 - one each for phase and for earth fault of a zone; or with 12 - one each per phase and for earth. With these variations, it is then a challenge to identify, which instance is for what; prefixes that may be used to differentiate the instances are not standardized, so if you are lucky, you can guess, what the vendor meant with PhsPDIS1 orGndPDIS6; if you are not, you will find PDIS1 to PDIS6 only. This situation should be improved in the future. Within SCL, we introduced new possibilities to identify functions and sub-functions as I reported in an article in PACW 22.
The problem with GGIO is discussed in many LinkedIn threads as well as in TISSUES. There are 2 main categories of GGIO usage:

  • The first one is due to the lack of better knowledge or because somebody wants to have a non-standardized representation of information; e.g. - of a breaker position as two binary signals (52a/52b) instead of double point information
  • The second one is due to configurable IEDs and IED engineering constraints. An IED that is supplied by a vendor implements certain functions like the control of a switch or an auto-reclosing as standard SW blocks. In that case, IEC 61850 data objects are used in a good design (note that not all products are good designs)

However, IEDs also provide user configurable I/O and logic blocks. When the IED leaves the factory, I/O and user configurable logic do not yet have any semantic meaning.

So the only way to include them as an IEC 61850 data object in an ICD file is through the usage of GGIO - which is correct since at this stage, they are generic signals.
However, later the design engineer doing the IED configuration should be able to change the name of a data object based on the semantic usage.

As an example, if the design engineer connects the alarm contact of an insulation gas sensor to one of these generic input contacts, he should be able to transmit the resulting information in IEC 61850 as SIMG.InsAlm rather than as GGIO.Alm.
This could be done as part of the pre-engineering of the IED and then be incorporated in the customized ICD file or later during the IED design and then be fed back to the system tool as updated IID file. The mechanisms in IEC 61850 are there - we just lack the support of them in today's IED configuration tools.

Now that vendors start to consolidate their first generation IEC 61850 products incorporating Edition 2, we will see better IEC 61850 products on the market.
So I am confident that we will soon be able to benefit more from the IEC 61850 features.
Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and he is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is international advisor to the board of the UCA international users group.

Power. Flexible. Easergy.
Let?s start with organization in protection testing