IEC 61850 - Later Binding and Message Binding

Owned by Davood Sooran (Deactivated)
Aug 30, 2024
9 min read

Below you will find the problem description related to the Later Binding and Message Binding:

The functionality of IEC 61850 operates on two layers: the IEC 61850 interface and the underlying functionality managed by the vendor's data model. Below is an example of this communication in the context of overcurrent protection. The interface layer comprises the IEC 61850 data model, featuring elements such as Operate, Start, and more.


We observe a similar structure on the other side of the communication. Information can be transmitted from one interface to another, such as a GOOSE op.general signal. For example, when the left IED trips, it sends this signal to the interface of the right IED. The question then arises: how does the right IED receive this signal?

It is important to note that an additional process exists between the interface and the section where the PTOC is defined. This involves various methods for handling subscriptions, which refer to the connection between the left and right interfaces. Specifically, a GOOSE control block is created on the left side, and an External Reference is established on the right side.

However, the question that arises here is whether the message received by the right interface knows where to go within the IED. To address this, there are two processes that can be followed.


Later Binding:

Later binding allows you to create specific External References in the interface and automatically link them to certain functionalities in the PTOC. This setup is then exported as an ICD or IID file and used in the configuration process and system configuration tool. In the SCL file, it appears like this:


<ExtRef pLN="..." pDO="..." pDA="..." pServT="..." intAddr="..." />


In the SCL file, the `intAddr` attribute represents the connection between the External Reference and the functionality in the PTOC. The other four attributes can limit the data you want to subscribe to within that information.

In later binding, you first create the External Reference and establish the link. Then, you bind to the already existing External Reference.


Message/Data Binding / ICT Binding:


In this case, the binding is not done before the system configuration but is completed afterward. First, you create a GOOSE control block, and then you create an external reference in your interface. This external reference looks a bit different:


<ExtRef iedName="..." ldInst="..." prefix/lnClass/lnInst="..." doName="..." daName="..." ServiceType="..." srcXXX="..." />



This external reference points to the GOOSE control block in the interface of the left-side IED. However, it does not contain information about the internal signal routing on the right side, specifically between the interface and the PTOC.

The key difference is that the `ExtRef` in the SCL file:


<ExtRef pLN="..." pDO="..." pDA="..." pServT="..." intAddr="..." />

is typically created by an ICT or vendor tool, while this `ExtRef`:

<ExtRef iedName="..." ldInst="..." prefix/lnClass/lnInst="..." doName="..." daName="..." ServiceType="..." srcXXX="..." />

is generated by a system configuration tool.


Currently, we follow a rule where "Later Binding" refers to any configuration that includes an Internal Address (`intAddr`), while anything without an Internal Address (`intAddr`) is considered Data or Message Binding.

There's a challenge with this approach. Let's assume we're dealing with process data binding. You create the necessary configuration and then import this SCD file into an ICT tool. Afterward, you establish the connection between the interface and the PTOC. What happens next is that the `intAddr` gets written into your SCL file.


Now, you save the file like this. According to the IEC 61850 standard, there is a table outlining the different stages and purposes of an SCL file, with the final stage being for documentation purposes. In the documentation stage, the goal is typically to include all relevant information:


<ExtRef iedName="..." ldInst="..." prefix/lnClass/lnInst="..." doName="..." daName="..." ServiceType="..." srcXXX="..." />

When you reopen this file in a tool like OpenSCD, you'll see the internal address (`intAddr`) and related attributes. At first glance, it might appear to be a later binding, but it is not—it wasn't created as a later binding type attribute. This distinction has important implications.

The first implication is that these types of signals do not appear in message or data binding plugins, even though users might expect them to, given that the same plugin was used to configure them. This discrepancy can cause confusion and operational issues, as the signals aren't displayed where users anticipate.

This issue is significant because it creates unpredictability for the user, making it difficult to locate the necessary information later on. This is the first major problem. The second issue relates to how we handle later binding and data binding.

When we perform later binding, we add subscriptions to external references like this:


<ExtRef iedName="..." ldInst="..." pLN="..." pDO="..." pDA="..." pServT="..." intAddr="..." />

When we break the subscription, we remove certain attributes, resulting in something like this:


<ExtRef pDO="..." pDA="..." pServT="..." intAddr="..." />

However, when we perform data binding in OpenSCD, we create the entire external reference. If we need to remove it, we must delete the entire external reference because it wasn't created by an ICT tool but by us. To manage this, we sometimes add a tag to help us track these changes.

What should have happened is that we should have created an additional subscription type, indicating that it’s not coming from, for example, Q01BCU, but from Q02BCU. The important thing here is that this Logical Node was already part of the data model, so we can't simply remove it.

This approach would ensure better handling of subscriptions and data bindings, preventing the issues currently faced when users interact with these configurations.



And This LN is an element that we added to the data model, so it needs to be removed when we undo the subscription.



What we do is tag this element with a private tag.


The important thing is that by tagging it, our tool can recognize later on that it’s something we created, so it knows to remove it as well. This is a tactic we currently use with external references. Without this tagging, we would encounter problems.

You can see below how the system indicates that these elements are currently subscribed using a data message binding approach.


Now, if we add a small change, such as intAddr=something, and save it, then go to the message binding plugin and check Q02, you'll notice that it's only partially subscribed, meaning the message isn’t fully recognized.




When we switch to later binding and look for the GCB information, you can see that it incorrectly shows a message binding indication, which is strange. It shouldn't appear this way because we didn't configure it with later binding information.



This raises the question: how should we handle this issue? Our rule for determining whether we are in a later binding or data binding process works well up until the documentation stage of an SCL file—then it falls apart.

One potential solution is to simply accept this limitation. Alternatively, we could modify the process by adding a tag when creating the ExtRef.



By tagging it, we can track exactly which plugin created the entry and ensure that the message is displayed in the correct plugin. This approach would help us manage the inconsistency more effectively.




 Approaches to Address These Issues:

Here are some potential approaches to address these issues:

1. Use a Custom Attribute

Adding a custom attribute to indicate the binding type is a straightforward solution. Although it introduces a non-standard element, it can be highly effective for internal use. For example:

<ExtRef iedName="IED1" ldInst="LD1" lnClass="GGIO" lnInst="1" doName="St" daName="stVal" intAddr="Input1" bindingType="LaterBinding"/>

Or for Message Binding:

<ExtRef iedName="IED2" ldInst="LD2" lnClass="GGIO" lnInst="1" doName="St" daName="stVal" intAddr="Input1" bindingType="MessageBinding"/>

Advantages:

  • Clear and explicit distinction between binding types.

  • Easy to query, search, and manage ExtRefs based on the binding type.

Disadvantages:

  • Non-standard approach, which might cause compatibility issues with third-party tools.

  • Requires custom tools or modifications to existing tools for validation and processing.



2. Use the desc Attribute for Descriptive Information 

The desc (description) attribute is part of the IEC 61850 standard and can be used to encode information about the binding type. This avoids adding non-standard attributes but still allows for clear differentiation:

<ExtRef iedName="IED1" ldInst="LD1" lnClass="GGIO" lnInst="1" doName="St" daName="stVal" intAddr="Input1" desc="LaterBinding"/>

Or for Message Binding:

<ExtRef iedName="IED2" ldInst="LD2" lnClass="GGIO" lnInst="1" doName="St" daName="stVal" intAddr="Input1" desc="MessageBinding"/>

Advantages:

  • Standard-compliant, avoiding issues with tools and validation.

  • Easy to implement with existing tools that support the desc attribute.

Disadvantages:

  • Not as explicitly linked to binding types as a dedicated attribute.

  • Could be overlooked or misused for other descriptions.

(After careful consideration, it has been determined that this solution cannot be used and is not applicable to address the issue.)



3. Use the Private Tag

Using the Private tag in IEC 61850 SCL files is a viable approach for adding custom, non-standard information without violating the IEC 61850 standard. The Private element is specifically designed to allow vendors or users to include proprietary or custom data within SCL files while maintaining overall standard compliance.


How the Private Tag Works

The Private tag is an optional element defined within the IEC 61850 standard that allows the inclusion of non-standard, proprietary information. The content inside a Private tag is not regulated by the IEC 61850 standard, meaning you can include custom attributes or data that are specific to your system.


Example of Using the Private Tag

You can use the Private tag within an ExtRef element to store the binding type information:

<ExtRef iedName="IED1" ldInst="LD1" lnClass="GGIO" lnInst="1" doName="St" daName="stVal" intAddr="Input1">
    <Private type="BindingInfo">
        <BindingType>LaterBinding</BindingType>
    </Private>
</ExtRef>

<ExtRef iedName="IED2" ldInst="LD2" lnClass="GGIO" lnInst="1" doName="St" daName="stVal"> intAddr="Input1">
    <Private type="BindingInfo">
        <BindingType>MessageBinding</BindingType>
    </Private>
</ExtRef>


In this example:

  • The Private element is used to encapsulate the custom data, here defined as <BindingType>.

  • The type attribute of the Private element can be used to categorize the custom data. In this case, it’s set to "BindingInfo", but we can choose any appropriate value.

Advantages:

  • The Private tag is fully compliant with the IEC 61850 standard, allowing you to extend the SCL file without risking compatibility with other compliant tools and systems.

  • You can define any structure or attributes within the Private tag, giving you the flexibility to add whatever custom information you need.

  • Since the Private tag is a recognized part of the IEC 61850 standard, other systems and tools that comply with the standard will understand that this data is custom and can choose to ignore it or handle it as needed.

  • The custom data is clearly separated from the standard attributes and elements, reducing the risk of confusion or misinterpretation.

Disadvantages:

  • Not all tools might display or allow easy editing of content within Private tags, potentially limiting how this information can be accessed or managed through graphical user interfaces.

  • Any processing, validation, or interpretation of the data within a Private tag requires custom scripts, tools, or logic, as this data will not be handled by standard IEC 61850 tools.

  • If not well-documented, the custom data inside a Private tag might be misunderstood or misused by others working with the SCL files, especially in larger teams or projects involving multiple stakeholders.