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

Описанная ситуация повторяется из раза в раз на наших семинарах по стандарту МЭК 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.