Цифровая Подстанция – это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?
Всем, кому интересно разобраться в этой теме, – welcome под кат!
Прежде чем переходить непосредственно к Цифровой Подстанции и нюансам построения ЛВС, предлагаю краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками. Ликбез мы спрятали под спойлер.
Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:
И уже после этого обсуждать multicast…
Цифровая Подстанция – это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.
Соответственно, в цифровом виде здесь передаются все данные:
Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО «Россети» определяет следующее определение и критерии ЦПС:
Определение:
Цифровая подстанция — автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.
Критерии:
В составе Цифровой Подстанции есть следующие системы:
Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже – пишите в комментарии.
Расскажем про это отдельно ;-)
Какие данные передаются в ЛВС?
Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина – это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.
Структурная схема электроэнергетического объекта в соответствии с МЭК 61850
На структурной схеме изображены шины:
Терминалы релейной защиты участвуют и в горизонтальной и в вертикальной связи, а также используют измерения, поэтому они подключаются ко всем шинам.
Через шину «Передача сигналов РЗА» терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.
Через шину «Передача мгновенных значений напряжений и токов» реализована передача измерений. К этой шине подключаются устройства измерения – трансформаторы тока и напряжения, а также терминалы релейной защиты.
Также к шине «Передача мгновенных значений напряжений и токов» подключается сервер АСКУЭ, который также забирает к себе измерения для учета.
А шина «Мониторинг/Управление» служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.
С сервера АСУ ТП данные отправляются в диспетчерский пункт.
Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.
На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.
Архитектура Цифровой Подстанции
На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.
Архитектура разбита на три уровня:
Уровень станции/подстанции включает в себя АРМы и сервера.
Уровень присоединения включает в себя все технологическое оборудование.
Уровень процесса включает в себя измерительное оборудование.
Также есть две шины для объединения уровней:
Шина станции/подстанции объединяет в себе функции шины «Мониторинг/Управление» и шины «Передача сигналов РЗА». А шина процесса выполняет функции шины «Передача мгновенных значений напряжения и тока».
Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры «Издатель-Подписчик». Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.
До цифровой подстанции в энергетике горизонтальная связь реализовывалась при помощи связи точка-точка между терминалами. В качестве интерфейса использовался либо медный, либо оптический кабель. Данные передавались по проприетарным протоколам.
К этой связи предъявлялись очень высокие требования, т.к. по этим каналам передавали сигналы срабатывания защит, положения коммутационных аппаратов и т.д. От этой информации зависел алгоритм оперативной блокировки терминалов.
В случае если данные будут передавать медленно или негарантированно, велика вероятность, что какой-то из терминалов не получит актуальной информации по текущей ситуации и может подать сигнал на отключение или включение коммутационного аппарата, когда на нем, например, будут проводиться какие-то работы. Или УРОВ не отработает вовремя и КЗ распространится на остальные части электрической схемы. Все это чревато большими денежными потерями и угрозой человеческой жизни.
Поэтому данные должны были передаваться:
Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).
GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.
В рамках этого протокола, терминалы релейной защиты обмениваются GOOSE-сообщениями между собой.
Переход от связи точка-точка к ЛВС подхода не изменил. Данные по-прежнему необходимо передавать надежно, гарантированно и быстро. Поэтому для GOOSE-сообщений используется несколько непривычный механизм передачи данных. Про него чуть позже.
Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).
SV-потоки – это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой – частотой дискретизации.
Частота дискретизации — частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.
Частота дискретизации 80 выборок в секунду
Состав SV-потоков описан в МЭК61850-9-2 LE.
SV-потоки передаются через шину процесса.
Шина процесса — коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).
SV-потоки, также как и GOOSE-сообщения, должны передаваться быстро. Если измерения будут передаваться медленно, то терминалы могут вовремя не получить значение тока или напряжения, необходимое для срабатывания защиты, и тогда короткое замыкание распространится на большую часть электрической сети и причинит большой ущерб.
Как упоминалось выше, для закрытия требований по передаче данных для горизонтальной связи, GOOSE передаются несколько непривычно.
Во-первых, они передаются на канальном уровне и имеют свой Ethertype – 0x88b8. Это обеспечивает высокую скорость передачи данных.
Теперь необходимо закрыть требования гарантированности и надежности.
Очевидно, что для гарантированности необходимо понимать доставлено ли сообщение, но мы не можем организовать отправки подтверждений получения, как, например, это делается в TCP. Это значительно снизит скорость передачи данных.
Поэтому для передачи GOOSE используется архитектура «Издатель-Подписчик».
Архитектура «Издатель – Подписчик»
Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом — через чуть больший и так далее. В итоге время увеличивается до Т0.
Принцип передачи GOOSE-сообщений
Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке.
SV-потоки также передаются на канальном уровне, имеют свой Ethertype — 0x88BA и передаются по модели «Издатель – Подписчик».
Нюансы multicast-передачи в Цифровой подстанции
Но в «энергетическом» multicast’е есть свои нюансы.
Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для «энергетического» multicast используются свои группы для рассылки.
В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО «ФСК» определяет собственные диапазоны multicast-рассылки.
Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-01-FF.
Для GOOSE-сообщений: от 01-0C-CD-01-00-00 до 01-0C-CD-01-01-FF.
Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее — терминалы релейной защиты не поддерживают ни IGMP, ни PIM, ни какие-либо еще multicast-протоколы. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.
Другими словами – вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой – никак.
А SV-потоки – это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.
Какой тогда выход?
Простой — использовать старые проверенные VLAN.
Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.
Поэтому можно выделить простое правило пусконаладки – «Сеть не работает? – Disable IGMP!»
Но может быть все-таки можно как-то организовать ЛВС Цифровой Подстанции на основе multicast? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:
Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО «ФСК ЕЭС». СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.
Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.
На этом все про multicast…
Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.
Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.
СТО 34.01-21-004-2019 говорит о том, что VLAN’ы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.
СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.
Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.
Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020
С точки зрения управления потоками – это все. Хотя в этих СТО есть еще много чего пообсуждать – начиная с разнообразных архитектур и заканчивая настройками L3 — мы это обязательно сделаем, но в следующий раз.
А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.
В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.
Для управления потоками используются старые добрые VLAN’ы. При этом использование VLAN регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.
Полезные ссылки:
Обучающий курс «Цифровая подстанция от Phoenix Contact».
Решения для ЦПС от Phoenix Contact.
Всем, кому интересно разобраться в этой теме, – welcome под кат!
Как данные передаются в сети и зачем управлять multicast-потоками?
Прежде чем переходить непосредственно к Цифровой Подстанции и нюансам построения ЛВС, предлагаю краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками. Ликбез мы спрятали под спойлер.
Типы передачи данных
Типы траффика в ЛВС
Существует четыре типа передачи данных:
Чтобы не запутать карты, давайте, прежде чем переходить к multicast, кратко проговорим про другие три типа передачи данных.
Прежде всего, давайте вспомним, что внутри ЛВС адресация между устройствами выполняется на основе MAC-адресов. В любом передаваемом сообщении есть поля SRC MAC и DST MAC.
SRC MAC – source MAC – MAC-адрес отправителя.
DST MAC – destination MAC – MAC-адрес получателя.
Коммутатор на основании этих полей передает сообщения. Он смотрит DST MAC, находит его в своей таблице MAC-адресов и отправляет сообщение на тот порт, который указан в таблице. Также он смотрит и SRC MAC. Если такого MAC-адреса в таблице нет, то добавляется новая пара «MAC-адрес – порт».
Теперь давайте поговорим подробнее про типы передачи данных.
Unicast – это адресная передача сообщений между двумя устройствами. По сути, это передача данных точка-точка. Другими словами, два устройства для общения друг с другом всегда используют Unicast.
Передача Unicast-трафика
Broadcast – это широковещательная рассылка. Т.е. рассылка, когда одно устройство отправляет сообщение всем остальным устройствам в сети.
Чтобы отправить широковещательное сообщение, отправитель в качестве DST MAC указывает адрес FF:FF:FF:FF:FF:FF.
Передача Broadcast-трафика
Unknown Unicast, на первый взгляд, очень похож на Broadcast. Но разница между ними есть — сообщение рассылается всем участникам сети, но предназначено только одному устройству. Это как сообщение в торговом центре с просьбой перепарковать авто. Услышат это сообщение все, но откликнется только один.
Когда коммутатор принимает фрейм и не может найти Destination MAC из него в таблице MAC-адресов, то он просто рассылает это сообщение во все порты, кроме того, с которого принял его. На подобную рассылку ответит только одно устройство.
Передача Unknown Unicast-трафика
Multicast – это рассылка сообщения на группу устройств, которые «хотят» получать эти данные. Это очень похоже на вебинар. Он транслируется на весь Интернет, но подключаются к нему только те люди, которым данная тематика интересна.
Такая модель передачи данных называется «Издатель — Подписчик». Есть один Издатель, который отправляет данные и Подписчики, которые эти данные хотят получать – подписываются на них.
При multicast-рассылке сообщение отправляется с реального устройства. В качестве Source MAC в фрейме указывается MAC отправителя. А вот в качестве Destination MAC — виртуальный адрес.
Устройство должно подключиться к группе, чтобы получать данные из нее. Коммутатор перенаправляет информационные потоки между устройствами – он запоминает, с каких портов данные передаются, и знает, на какие порты эти данные нужно отправлять.
Передача Multicast-трафика
Важный момент, что в качестве виртуальных групп чаще используются IP-адреса, но т.к. в разрезе данной статьи речь идет об энергетике, то мы будем говорить про MAC-адреса. В протоколах семейства МЭК 61850, которые используются для Цифровой Подстанции, разделение на группы производится на основе MAC-адресов
MAC-адрес – это 48-битное значение, которое уникально идентифицирует устройство. Он разбит на 6 октет. Первые три октета содержат информацию о производителе. 4, 5 и 6 октеты назначаются производителем и являются номером устройства.
Структура MAC-адреса
В первом октете восьмой бит отвечает за то, является ли данное сообщение unicast или multicast. Если восьмой бит равен 0, то данный MAC-адрес – это адрес реального физического устройства.
А если восьмой бит равен 1, то этот MAC-адрес виртуальный. То есть, этот MAC-адрес принадлежит не реальному физическому устройству, а виртуальной группе.
Виртуальную группу можно сравнить с вышкой радиовещания. Радиокомпания транслирует на эту вышку какую-то музыку, а те, кому хочется ее послушать, – настраивают приемники на нужную частоту.
Также, например, IP-видеокамера отправляет данные в виртуальную группу, а те устройства, которые хотят эти данные получать, подключаются к этой группе.
Восьмой бит первого октета MAC-адреса
Если на коммутаторе не включена поддержка multicast, то он будет multicast-поток воспринимать как широковещательную рассылку. Соответственно, если таких потоков будет много, то мы очень быстро забьем сеть «мусорным» трафиком.
Основная идея multicast — с устройства отправляется только одна копия трафика. Коммутатор определяет, на каких портах находятся подписчики, и передает на них данные от отправителя. Тем самым, multicast позволяет значительно сократить данные, передаваемые через сеть.
Понятно, что недостаточно просто отправлять одну копию трафика на какой-то MAC-адрес, восьмой бит первого октета которого равен 1. Подписчики должны уметь подключаться к этой группе. А коммутаторы должны понимать, с каких портов данные приходят, и на какие порты их необходимо передавать. Только тогда multicast позволит оптимизировать сети и управлять потоками.
Для реализации этого функционала существуют multicast-протоколы. Наиболее распространенные:
В рамках этой статьи мы по касательной расскажем про общий принцип действия этих протоколов.
Коммутатор с поддержкой IGMP запоминает, на какой порт приходит multicast-поток. Подписчики должны отправить IMGP Join сообщение для подключения к группе. Коммутатор добавляет порт, с которого пришел IGMP Join, в список нисходящих интерфейсов и начинает передавать multicast-поток туда. Коммутатор постоянно посылает IGMP Query сообщения на нисходящие порты, чтобы проверить, нужно ли продолжать передавать данные. Если с порта пришло сообщение IGMP Leave или не было ответа на сообщение IGMP Query, то вещание на него прекращается.
У протокола PIM есть две реализации:
Протокол PIM DM действует от обратного, в сравнении с IGMP. Коммутатор изначально рассылает multicast-поток как широковещательный – на все порты, кроме того, с которого он был получен. Затем отключает поток на тех портах, откуда пришли сообщения о том, что он не нужен.
PIM SM по принципу работы близко к IGMP.
Если очень грубо обобщить общий принцип работы multicast – Издатель отправляет multicast-поток на определенную MAC-группу, подписчики отправляют запросы на подключение к этой группе, коммутаторы управляют данными потоками.
Почему мы настолько поверхностно прошлись по multicast? Давайте поговорим про специфику ЛВС Цифровой Подстанции, чтобы понять это.
UPD: Протоколы IGMP и PIM — это протоколы сетевого уровня и они работают с IP-адресами. При передаче данных IP-группа транслируется в MAC-адрес. Подробнее про это можно посмотреть, например, здесь. Есть протоколы, которые используют только MAC-адреса для рассылки (подробнее).
Существует четыре типа передачи данных:
- Broadcast – широковещательная рассылка.
- Unicast – обмен сообщениями между двумя устройствами.
- Multicast – рассылка сообщений на определенную группу устройств.
- Unknown Unicast – широковещательная рассылка с целью найти одно устройство.
Чтобы не запутать карты, давайте, прежде чем переходить к multicast, кратко проговорим про другие три типа передачи данных.
Прежде всего, давайте вспомним, что внутри ЛВС адресация между устройствами выполняется на основе MAC-адресов. В любом передаваемом сообщении есть поля SRC MAC и DST MAC.
SRC MAC – source MAC – MAC-адрес отправителя.
DST MAC – destination MAC – MAC-адрес получателя.
Коммутатор на основании этих полей передает сообщения. Он смотрит DST MAC, находит его в своей таблице MAC-адресов и отправляет сообщение на тот порт, который указан в таблице. Также он смотрит и SRC MAC. Если такого MAC-адреса в таблице нет, то добавляется новая пара «MAC-адрес – порт».
Теперь давайте поговорим подробнее про типы передачи данных.
Unicast
Unicast – это адресная передача сообщений между двумя устройствами. По сути, это передача данных точка-точка. Другими словами, два устройства для общения друг с другом всегда используют Unicast.
Передача Unicast-трафика
Broadcast
Broadcast – это широковещательная рассылка. Т.е. рассылка, когда одно устройство отправляет сообщение всем остальным устройствам в сети.
Чтобы отправить широковещательное сообщение, отправитель в качестве DST MAC указывает адрес FF:FF:FF:FF:FF:FF.
Передача Broadcast-трафика
Unknown Unicast
Unknown Unicast, на первый взгляд, очень похож на Broadcast. Но разница между ними есть — сообщение рассылается всем участникам сети, но предназначено только одному устройству. Это как сообщение в торговом центре с просьбой перепарковать авто. Услышат это сообщение все, но откликнется только один.
Когда коммутатор принимает фрейм и не может найти Destination MAC из него в таблице MAC-адресов, то он просто рассылает это сообщение во все порты, кроме того, с которого принял его. На подобную рассылку ответит только одно устройство.
Передача Unknown Unicast-трафика
Multicast
Multicast – это рассылка сообщения на группу устройств, которые «хотят» получать эти данные. Это очень похоже на вебинар. Он транслируется на весь Интернет, но подключаются к нему только те люди, которым данная тематика интересна.
Такая модель передачи данных называется «Издатель — Подписчик». Есть один Издатель, который отправляет данные и Подписчики, которые эти данные хотят получать – подписываются на них.
При multicast-рассылке сообщение отправляется с реального устройства. В качестве Source MAC в фрейме указывается MAC отправителя. А вот в качестве Destination MAC — виртуальный адрес.
Устройство должно подключиться к группе, чтобы получать данные из нее. Коммутатор перенаправляет информационные потоки между устройствами – он запоминает, с каких портов данные передаются, и знает, на какие порты эти данные нужно отправлять.
Передача Multicast-трафика
Важный момент, что в качестве виртуальных групп чаще используются IP-адреса, но т.к. в разрезе данной статьи речь идет об энергетике, то мы будем говорить про MAC-адреса. В протоколах семейства МЭК 61850, которые используются для Цифровой Подстанции, разделение на группы производится на основе MAC-адресов
Краткий ликбез про MAC-адрес
MAC-адрес – это 48-битное значение, которое уникально идентифицирует устройство. Он разбит на 6 октет. Первые три октета содержат информацию о производителе. 4, 5 и 6 октеты назначаются производителем и являются номером устройства.
Структура MAC-адреса
В первом октете восьмой бит отвечает за то, является ли данное сообщение unicast или multicast. Если восьмой бит равен 0, то данный MAC-адрес – это адрес реального физического устройства.
А если восьмой бит равен 1, то этот MAC-адрес виртуальный. То есть, этот MAC-адрес принадлежит не реальному физическому устройству, а виртуальной группе.
Виртуальную группу можно сравнить с вышкой радиовещания. Радиокомпания транслирует на эту вышку какую-то музыку, а те, кому хочется ее послушать, – настраивают приемники на нужную частоту.
Также, например, IP-видеокамера отправляет данные в виртуальную группу, а те устройства, которые хотят эти данные получать, подключаются к этой группе.
Восьмой бит первого октета MAC-адреса
Если на коммутаторе не включена поддержка multicast, то он будет multicast-поток воспринимать как широковещательную рассылку. Соответственно, если таких потоков будет много, то мы очень быстро забьем сеть «мусорным» трафиком.
В чем суть multicast?
Основная идея multicast — с устройства отправляется только одна копия трафика. Коммутатор определяет, на каких портах находятся подписчики, и передает на них данные от отправителя. Тем самым, multicast позволяет значительно сократить данные, передаваемые через сеть.
Как это работает в реальной ЛВС?
Понятно, что недостаточно просто отправлять одну копию трафика на какой-то MAC-адрес, восьмой бит первого октета которого равен 1. Подписчики должны уметь подключаться к этой группе. А коммутаторы должны понимать, с каких портов данные приходят, и на какие порты их необходимо передавать. Только тогда multicast позволит оптимизировать сети и управлять потоками.
Для реализации этого функционала существуют multicast-протоколы. Наиболее распространенные:
- IGMP.
- PIM.
В рамках этой статьи мы по касательной расскажем про общий принцип действия этих протоколов.
IGMP
Коммутатор с поддержкой IGMP запоминает, на какой порт приходит multicast-поток. Подписчики должны отправить IMGP Join сообщение для подключения к группе. Коммутатор добавляет порт, с которого пришел IGMP Join, в список нисходящих интерфейсов и начинает передавать multicast-поток туда. Коммутатор постоянно посылает IGMP Query сообщения на нисходящие порты, чтобы проверить, нужно ли продолжать передавать данные. Если с порта пришло сообщение IGMP Leave или не было ответа на сообщение IGMP Query, то вещание на него прекращается.
PIM
У протокола PIM есть две реализации:
- PIM DM.
- PIM SM.
Протокол PIM DM действует от обратного, в сравнении с IGMP. Коммутатор изначально рассылает multicast-поток как широковещательный – на все порты, кроме того, с которого он был получен. Затем отключает поток на тех портах, откуда пришли сообщения о том, что он не нужен.
PIM SM по принципу работы близко к IGMP.
Если очень грубо обобщить общий принцип работы multicast – Издатель отправляет multicast-поток на определенную MAC-группу, подписчики отправляют запросы на подключение к этой группе, коммутаторы управляют данными потоками.
Почему мы настолько поверхностно прошлись по multicast? Давайте поговорим про специфику ЛВС Цифровой Подстанции, чтобы понять это.
UPD: Протоколы IGMP и PIM — это протоколы сетевого уровня и они работают с IP-адресами. При передаче данных IP-группа транслируется в MAC-адрес. Подробнее про это можно посмотреть, например, здесь. Есть протоколы, которые используют только MAC-адреса для рассылки (подробнее).
Что такое Цифровая Подстанция и зачем там нужен multicast?
Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:
- Кто участвует в передаче данных?
- Какие данные передаются в ЛВС?
- Какая типовая архитектура ЛВС?
И уже после этого обсуждать multicast…
Что такое Цифровая Подстанция?
Цифровая Подстанция – это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.
Соответственно, в цифровом виде здесь передаются все данные:
- Измерения.
- Диагностическая информация.
- Команды управления.
Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО «Россети» определяет следующее определение и критерии ЦПС:
Определение:
Цифровая подстанция — автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.
Критерии:
- дистанционная наблюдаемость параметров и режимов работы оборудования и систем, необходимых для нормального функционирования без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
- обеспечение телеуправления оборудованием и системами для эксплуатации ПС без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
- высокий уровень автоматизации управления оборудованием и системами с применением интеллектуальных систем управления режимами работы оборудования и систем;
- дистанционная управляемость всеми технологическими процессами в режиме единого времени;
- цифровой обмен данными между всеми технологическими системами в едином формате;
- интегрированность в систему управления электрической сетью и предприятием, а также обеспечение цифрового взаимодействия с соответствующими инфраструктурными организациями (со смежными объектами);
- функциональная и информационная безопасность при цифровизации технологических процессов;
- непрерывный мониторинг состояния основного технологического оборудования и систем в режиме онлайн с передачей необходимого объема цифровых данных, контролируемых параметров и сигналов.
Кто участвует в передаче данных?
В составе Цифровой Подстанции есть следующие системы:
- Системы релейной защиты. Релейная защита – это практически «сердце» Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
▸Горизонтальная связь – общение терминалов между собой.
▸Вертикальная связь – общение с сервером АСУ ТП.
▸Измерения – общение с измерительными устройствами.
- Системы коммерческого учета электроэнергии.Системы коммерческого учета общаются только с измерительными устройствами.
- Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.
Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже – пишите в комментарии.
Расскажем про это отдельно ;-)
Какие данные передаются в ЛВС?
Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина – это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.
Структурная схема электроэнергетического объекта в соответствии с МЭК 61850
На структурной схеме изображены шины:
- Мониторинг/Управления.
- Передача сигналов РЗА.
- Передача мгновенных значений напряжений и токов.
Терминалы релейной защиты участвуют и в горизонтальной и в вертикальной связи, а также используют измерения, поэтому они подключаются ко всем шинам.
Через шину «Передача сигналов РЗА» терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.
Через шину «Передача мгновенных значений напряжений и токов» реализована передача измерений. К этой шине подключаются устройства измерения – трансформаторы тока и напряжения, а также терминалы релейной защиты.
Также к шине «Передача мгновенных значений напряжений и токов» подключается сервер АСКУЭ, который также забирает к себе измерения для учета.
А шина «Мониторинг/Управление» служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.
С сервера АСУ ТП данные отправляются в диспетчерский пункт.
Какая типовая архитектура ЛВС?
Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.
На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.
Архитектура Цифровой Подстанции
На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.
Архитектура разбита на три уровня:
- Уровень станции/подстанции.
- Уровень присоединения.
- Уровень процесса.
Уровень станции/подстанции включает в себя АРМы и сервера.
Уровень присоединения включает в себя все технологическое оборудование.
Уровень процесса включает в себя измерительное оборудование.
Также есть две шины для объединения уровней:
- Шина станции/подстанции.
- Шина процесса.
Шина станции/подстанции объединяет в себе функции шины «Мониторинг/Управление» и шины «Передача сигналов РЗА». А шина процесса выполняет функции шины «Передача мгновенных значений напряжения и тока».
Особенности передачи Multicast в Цифровой Подстанции
Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры «Издатель-Подписчик». Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.
До цифровой подстанции в энергетике горизонтальная связь реализовывалась при помощи связи точка-точка между терминалами. В качестве интерфейса использовался либо медный, либо оптический кабель. Данные передавались по проприетарным протоколам.
К этой связи предъявлялись очень высокие требования, т.к. по этим каналам передавали сигналы срабатывания защит, положения коммутационных аппаратов и т.д. От этой информации зависел алгоритм оперативной блокировки терминалов.
В случае если данные будут передавать медленно или негарантированно, велика вероятность, что какой-то из терминалов не получит актуальной информации по текущей ситуации и может подать сигнал на отключение или включение коммутационного аппарата, когда на нем, например, будут проводиться какие-то работы. Или УРОВ не отработает вовремя и КЗ распространится на остальные части электрической схемы. Все это чревато большими денежными потерями и угрозой человеческой жизни.
Поэтому данные должны были передаваться:
- Надежно.
- Гарантированно.
- Быстро.
Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).
GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.
В рамках этого протокола, терминалы релейной защиты обмениваются GOOSE-сообщениями между собой.
Переход от связи точка-точка к ЛВС подхода не изменил. Данные по-прежнему необходимо передавать надежно, гарантированно и быстро. Поэтому для GOOSE-сообщений используется несколько непривычный механизм передачи данных. Про него чуть позже.
Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).
SV-потоки – это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой – частотой дискретизации.
Частота дискретизации — частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.
Частота дискретизации 80 выборок в секунду
Состав SV-потоков описан в МЭК61850-9-2 LE.
SV-потоки передаются через шину процесса.
Шина процесса — коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).
SV-потоки, также как и GOOSE-сообщения, должны передаваться быстро. Если измерения будут передаваться медленно, то терминалы могут вовремя не получить значение тока или напряжения, необходимое для срабатывания защиты, и тогда короткое замыкание распространится на большую часть электрической сети и причинит большой ущерб.
Зачем необходим multicast?
Как упоминалось выше, для закрытия требований по передаче данных для горизонтальной связи, GOOSE передаются несколько непривычно.
Во-первых, они передаются на канальном уровне и имеют свой Ethertype – 0x88b8. Это обеспечивает высокую скорость передачи данных.
Теперь необходимо закрыть требования гарантированности и надежности.
Очевидно, что для гарантированности необходимо понимать доставлено ли сообщение, но мы не можем организовать отправки подтверждений получения, как, например, это делается в TCP. Это значительно снизит скорость передачи данных.
Поэтому для передачи GOOSE используется архитектура «Издатель-Подписчик».
Архитектура «Издатель – Подписчик»
Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом — через чуть больший и так далее. В итоге время увеличивается до Т0.
Принцип передачи GOOSE-сообщений
Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке.
SV-потоки также передаются на канальном уровне, имеют свой Ethertype — 0x88BA и передаются по модели «Издатель – Подписчик».
Нюансы multicast-передачи в Цифровой подстанции
Но в «энергетическом» multicast’е есть свои нюансы.
Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для «энергетического» multicast используются свои группы для рассылки.
В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО «ФСК» определяет собственные диапазоны multicast-рассылки.
Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-01-FF.
Для GOOSE-сообщений: от 01-0C-CD-01-00-00 до 01-0C-CD-01-01-FF.
Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее — терминалы релейной защиты не поддерживают ни IGMP, ни PIM, ни какие-либо еще multicast-протоколы. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.
Другими словами – вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой – никак.
А SV-потоки – это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.
Какой тогда выход?
Простой — использовать старые проверенные VLAN.
Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.
Поэтому можно выделить простое правило пусконаладки – «Сеть не работает? – Disable IGMP!»
Нормативная база
Но может быть все-таки можно как-то организовать ЛВС Цифровой Подстанции на основе multicast? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:
- СТО 34.01-21-004-2019 — ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВЫХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВЫХ ЦИФРОВЫХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
- СТО 34.01-6-005-2019 — КОММУТАТОРЫ ЭНЕРГООБЪЕКТОВ. Общие технические требования.
- СТО 56947007-29.240.10.302-2020 — Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.
Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО «ФСК ЕЭС». СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.
Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.
На этом все про multicast…
Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.
Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.
СТО 34.01-21-004-2019 говорит о том, что VLAN’ы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.
СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.
Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.
Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020
С точки зрения управления потоками – это все. Хотя в этих СТО есть еще много чего пообсуждать – начиная с разнообразных архитектур и заканчивая настройками L3 — мы это обязательно сделаем, но в следующий раз.
А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.
Заключение
В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.
Для управления потоками используются старые добрые VLAN’ы. При этом использование VLAN регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.
Полезные ссылки:
Обучающий курс «Цифровая подстанция от Phoenix Contact».
Решения для ЦПС от Phoenix Contact.
