Disrespectful Sampled Values subscriber behaviour

Teaser: Some IEDs require that SV (or maybe GOOSE) messages on ingress port of the IED have proper VLAN tag (as configured in the subscription), thus resulting in failure to receive the untagged messages (or messages with another VLAN ID tag). Such behaviour of an IED is wrong but sometimes you can meet this. Read the full article to dig into the details.

Feb. 16, 2021, 2:07 p.m. | 549

This situation repeats every time during our IEC 61850 trainings, where we have extensive hands-on sessions with IEDs of different manufacturers. We have an exercise where one group configures IED to publish SV stream and another group configures subscription to this stream. And this second group always fails to achieve positive result until guided by the tutors. And as we will see in the end of this note this is not their fault.

The setup is always primitive. We have one Ethernet switch with default (factory) settings and SV publisher and subscriber connected to this switch. When the first group finalizes the configuration of SV publishing, they pass the configuration to the subscribing party. And they do the subscription. But it doesn’t work. They check if the SV stream is forwarded by the port of the switch where subscribing IED is connected to and it is. But still it doesn’t work. Both IEDs support 9-2LE (80 samples/cycle) and are provided by the same manufacturer within single lineup, known to be working seamlessly together in general.

To understand the origins of the problem and who is to blame in this situation, we need to take a closer look on Ethernet frame, how Ethernet switch processes certain fields of Ethernet frame and what it all means to subscribing IED.

Sampled Values is mapped onto IEEE 802.3 (Ethernet) with a header, called the VLAN tag according to IEEE 802.1Q:

This VLAN tag provides two functions:

  • prioritization of traffic;
  • logical segregation of traffic.

According to the picture above VLAN tag is announced by a specific Ethertype (0x8100), followed by a 3 bit priority field called Priority Code Point (PCP), a one-bit Drop Eligible Indicator (DEI) and a 12-bit field containing the VLAN identifier, or VID. According to IEC 61850-9-2, IEEE 802.1Q tag with all its fields shall be present in all published SV frames. As you will see, VID plays a crucial role in our situation, so we will focus on this field.

If VID is set by configuration, then this value must be in force, otherwise - it must have the value of zero.

Coming back to our situation we had quite a straightforward setup with two IEDs connected to the same Ethernet switch. And as mentioned before, this switch had default settings. In regard, to VLANs, this means that there is only one VLAN available in the switch (native VLAN) which is 1. All switch ports are members of this VLAN (Port VLAN Membership (PVMS) = 1) and all incoming untagged traffic (or traffic with VID = 0) is tagged with this value (Port VID (PVID) = 1). Published SV stream is configured to have VID equal to 1. Another thing, worth mentioning is that by default Ethernet switch forwards all frames untagged. So the graphical interpretation of this setup is like this:

Given that all published SV stream parameters are passed to subscriber as is, all should work. But does not. Looking closer and searching for possible inconsistency, attentive reader will point out that the only difference between forwarded and expected SV stream is the absence of IEEE 802.1Q tag. We give it a try and reconfigure Ethernet switch to forward tagged frames. Yes, it works. But should the availability of the IEEE 802.1Q tag and VID value really matter for subscription? Let's check the standard:

Turns out it should not matter for SV subscriber. More than that, it is not only due to the fact that frames can be forwarded untagged - they can also be forwarded tagged with another VID, when, for example, published SV is configured with VID = 0 and stream is tagged according to PVID setting or when at some point of the network VID is altered by intermediate switches.

If SV subscriber acts like this, which is not proper behaviour, you can spend quite a long time in identifying the issue. Check with products you use or plan to use in the future! Save your time!

P.s. The same is true for GOOSE.

Latest blog posts

When GOOSE can't fly!
When GOOSE can't fly!

Everyone who ever dealt with the commissioning of IEC 61850 based systems had situations when there were problems in establishing successful GOOSE communications between IEDs. The reasons for that are always different. There may be a fault of the commissioning engineer, a fault of the vendor or it may be a fault of both parties at the same time. We have faced such situation recently and this was the case when one could blame... decide yourself who is to blame in this situation, having read this note about nuances in configuring GOOSE-communications between IEDs of two different vendors.

Transmission of data structures in a GOOSE message
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.

Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.