Недостойное поведение подписчика Sampled Values

Тизер: Некоторые интеллектуальные электронные устройства (ИЭУ) требуют того, чтобы сообщения Sampled Values (или GOOSE), поступающие на их интерфейс, имели значение тега VLAN ID как задано при подписке. Указанное приводит к тому, что данные ИЭУ отказываются принимать и обрабатывать сообщения без тега VLAN ID или сообщения с иным значением тега VLAN ID. Указанное поведение подписчиков не является правильным, однако его можно встретить на практике. Прочитайте до конца, чтобы понять в чём заключается суть.

Feb. 23, 2021, 11:49 p.m. | 1147 Инжиниринг (SE)

Описанная ситуация повторяется из раза в раз на наших семинарах по стандарту МЭК 61850, на которых у нас присутствуют практические занятия с устройствами различных фирм-производителей. В программе есть упражнение, где одна группа, на одном ИЭУ, настраивает публикацию потока Sampled Values (SV), а вторая, на другом ИЭУ, настраивает его приём. И вторая группа всегда сталкивается с проблемой успешного завершения задания до тех пор, пока не будет сопровождении преподавателями. И в конце этой заметки мы увидим, что это не их ошибка.

Схема стенда всегда примитивна. Есть один коммутатор Ethernet с заводскими настройками и, как указано ранее, один издатель SV и один подписчик SV. Оба подключены к коммутатору. Когда первая группа завершает конфигурирование публикации потока SV, она передаёт конфигурацию сообщения второй группе. И по этим данным вторая группа осуществляет подписку. Но ничего не работает. Вторая группа сразу же проверяет перенаправляет ли коммутатор поток SV на тот порт, к которому подключен подписчик. И убеждается, что коммутатор сообщения успешно перенаправляет. Оба ИЭУ поддерживают профиль 9-2LE (80 выборок/период) и являются изделиями одного и того же производителя из одной и той же линейки. Точно известно, что они должны обмениваться данными без каких-либо проблем.

Для того, чтобы понять истоки проблемы и выяснить, кого можно винить в сложившейся ситуации, мы должны более детально рассмотреть кадр Ethernet; то, как коммутатор обрабатывает некоторые из полей кадра; и какое значение эти поля имеют для ИЭУ-подписчика.

Коммуникационный сервис Sampled Values использует кадр IEEE 802.3 (Ethernet) с заголовком VLAN согласно стандарту IEEE 802.1Q:

Тег VLAN обеспечивает выполнение следующих функций: - приоритезация трафика; - разделение трафика.

Согласно рисунку, представленному выше, тег VLAN анонсируется специфичным Ethernet-типом (Ethertype), имеющим значение 0x8100, за которым следуют: поле приоритета Priority Code Point (PCP) размером 3 бита; поле Drop Eligible Indicator (DEI) размером 1 бит; и поле идентификатора виртуальной локальной сети VID размером 12 бит. Согласно стандарту МЭК 61850-9-2, тег IEEE 802.1Q со всеми своими полями должен обязательно присутствовать во всех публикуемых кадрах SV. Как мы увидем ранее, тег VID будет играть решающую роль в рассматриваемой ситуации, поэтому обратим на него более пристальное внимание.

Если тег VID задан при конфигурации издателя для рассматриваемого потока SV, то это значение и должно присутствовать в кадре, если он не задан - тогда значение должно быть равно 0.

Вернёмся к рассмотрению нашей ситуации с двумя ИЭУ, подключенными к одному коммутатору Ethernet. Как было указано ранее, этот коммутатор имеет заводские настройки. С точки зрения VLAN это означает, что в коммутаторе имеется только одна виртуальная локальная сеть VLAN - 1. Все порты коммутатора являются членами данной виртуальной локальной сети (уставка Port VLAN Membership или PVMS для всех портов равна 1) и весь входящий не тегированный трафик (или сообщения с тегом VID равным 0) тегируются этой виртуальной локальной сетью (уставка Port VID или PVID равна 1). Согласно заданию на выполнение упражнения поток имеет тег VID также равный 1. Ещё один момент требует уточнения - по-умолчанию, со всех кадров, перенаправляемых коммутатором, снимается тег. Указанную схему можно представить следующим рисунком:

Учитывая то, что параметры публикуемого потока передаются в точности согласно конфигурации издателя, всё должно работать. Но не работает. Более детально анализируя ситуацию в поисках несоответствий, внимательный читатель отметит, что единственным отличием между кадром, который ожидает подписчик, и перенаправляем кадром, является тег IEEE 802.1Q - а именно его отсутствие в последнем. Что-ж, мы переконфигурируем наш коммутатор на перенаправление тегированных кадров. И всё работает! Но должно ли это иметь значение? Давайте обратимся к стандарту:

Согласно стандарту тег VID не должен иметь никакого значения для подписчика SV как критерий принятия решения, подписан он на поступающий на его интерфейс поток или нет. И это не только лишь потому, что коммутатор может снимать тег с перенаправляемых им кадров, но и потому что в процессе передачи, кадру может присваиваться и другое значение тега VID или же публикуемый издателем поток имеет дефолтное значение VID равное 0 и теггируется согласно уставка PVID порта коммутатора.

Если подписчик SV ведёт себя так, как описано, это не является должным его поведением, и вы можете потратить много времени на выяснение причин нестыковки ИЭУ. Проверьте работу ИЭУ, которые вы уже используете или тех ИЭУ, которые только планируете к использованию! Берегите своё время!

P.s. Всё тоже самое справедливо и для GOOSE.

Latest blog posts

Disrespectful Sampled Values subscriber behaviour
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.

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.