Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

May 22, 2020, 12:52 p.m. | 236 Инжиниринг (SE)

Functional Constraint specifies which services can be used to access data. One of the most frequently used functional constraint is ST (Status). ST denotes data, acquired from the process. Such data cannot be changed by operator or somehow re-configured. Those who had a chance to configure GOOSE-communications must have already seen FC=ST data, as this group includes signals regarding protection start and trip indications, switchgear statuses and etc. But not so many engineers do really care about functional constraints. And that may lead to some problems in real practice.

Using a simple example we will show how FC can be used and how this may influence the structure of transmitted GOOSE-messages.

Let’s say that we would like to include protection trip indication data in a single dataset: trip signal itself, quality and timestamp. If to put it straightforward, we will create a dataset, consisting of 3 elements, like this:

    <DataSet name="TESTINGDATA">

        <FCDA ldInst="LD" prefix="" lnClass="PTOC" lnInst="1" doName="Op" daName="general" fc="ST"/>
        <FCDA ldInst="LD" prefix="" lnClass="PTOC" lnInst="1" doName="Op" daName="q" fc="ST"/>
        <FCDA ldInst="LD" prefix="" lnClass="PTOC" lnInst="1" doName="Op" daName="t" fc="ST"/>

    </DataSet>

This entry is primitive: there is a logical device, overcurrent protection PTOC logical node with the operation data object Op, which, in turn, includes 3 data attributes. There is a question – why do we need FC here? Nothing for, actually. It is there just because SCL schema requires this attribute. Can we change the entry somehow? Yes, we can fit it into a single line, like this:

    <DataSet name="TESTINGDATA">

        <FCDA ldInst="LD" prefix="" lnClass="PTOC" lnInst="1" doName="Op" fc="ST"/>

    </DataSet>

What has changed? We have not specified data attributes explicitly. Now FC comes into play. This form of entry means that dataset will include all the attributes of FC=”ST” from Op data object. In this case – general, q, t.

Is this entry correct? Yes.

Will the structure of the sent GOOSE message change? Let’s see.

For this experiment, we have taken SIPROTEC 7SJ801 protection IED. We will not cover in details how we created IEC 61850 station and GOOSE application in DIGSI and just get down to business. We will create 2 GOOSE-messages with two datasets, which include the very same data. But these will be different datasets. We must say that we have created datasets which are different from those described earlier. This does not influence the results of the experiment, though.

First, we will implement the first example and we will specify data attributes explicitly. DIGSI does so by default. If user chooses FC/DA mapping option in DIGSI, there will be a window presented where user can select required data attributes (Fig. 1).

Fig. 1. Specification of data attributes explicitly. Fig. 1. Specification of data attributes explicitly.

The following SCL entry, describing dataset, will correspond to the picture above (private elements have been deleted for the sake of simplicity):

    <DataSet name="DataSet">

        <FCDA ldInst="CTRL" prefix="button" lnClass="GGIO" lnInst="1" doName="SPCSO9" fc="ST" daName="stVal"/>
        <FCDA ldInst="CTRL" prefix="button" lnClass="GGIO" lnInst="1" doName="SPCSO9" fc="ST" daName="q"/>
        <FCDA ldInst="CTRL" prefix="button" lnClass="GGIO" lnInst="1" doName="SPCSO9" fc="ST" daName="t"/>

    </DataSet>

It is not difficult to see that this entry corresponds to the entry, presented in the beginning of this paper.

Okay, let’s create the second dataset, constructed with functional constraints. For this user has to uncheck specific data attributes and to check FC (ST in our case) (Fig. 2):

Fig. 2. Creation of datasets with functional constraints. Fig. 2. Creation of datasets with functional constraints.

Using SCL, such dataset can be described in a following way:

    <DataSet name="FCD">

        <FCDA ldInst="CTRL" prefix="button" lnClass="GGIO" lnInst="1" doName="SPCSO9" fc="ST"/>

    </DataSet>

That is what we need.

It is worth noting that described sequence of actions (uncheck specific attributes and check FC) does not work in every version of DIGSI. In version 4.87 it has not been possible. Though it has been possible to create such dataset manually – for this user had to edit SCD file, exported from DIGSI, and then import it in DIGSI again.

Now, let’s load configuration to SIPROTEC and check GOOSE-message in Wireshark. GOOSE-message in Fig. 3 is sent according to the first configuration (Fig. 1).

Fig. 3. Transmitting data attributes. Fig. 3. Transmitting data attributes.

Everything is as expected: stVal, q and t. HEX view is there for the information.

Now, let’s check for GOOSE-message, which dataset has been constructed using FC (Fig. 4).

Fig. 4. Transmitting a structure. Fig. 4. Transmitting a structure.

Not experienced user will not notice any difference. More experienced user will see that inside Data block there is no sequence of elements, but a Structure, which includes a sequence of aforementioned data attributes. It is also worth noting that the number of elements, transmitted in dataset, equals to 1 instead of 3 (which is true for the first case).

Fig. 5. PIXIT extract for GOOSE subscribe model.

For applications with good BER-decoder there will be no problems in decoding and interpretation of the data from such GOOSE-message. But described difference may be a source of a problem, which is difficult to identify/troubleshoot. Particularly, it may lead to interoperability problems between IEDs of different vendors and even between IEDs of the very same vendor, but of different series. Be careful and check PIXIT (especially in GOOSE Subscribe part) for IEDs you are using (Fig. 5).

Latest blog posts

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.

Alex Apostolov about the past, present and the future of relay protection
Alex Apostolov about the past, present and the future of relay protection

The new episode of Big Energy, produced by Tekvel team, is already on YouTube. This time we met Alex Apostolov - editor-in-chief of PAC World magazine and principal engineer of OMICRON electronics - who is one of the most well-known and reputable protection and control engineers in the world. Enjoy, like and share with engineers community!

Time synchronization — vulnerability of digital substation?
Time synchronization — vulnerability of digital substation?

In papers and presentations you can often meet statements like 'No time synchronization — no digital substation' or 'Loss of time synchronization leads to malfunction of protection and control (PAC) functions in digital substation'. Is it really true? Let's find out.