- Передача Unicast, Broadcast и Multicast трафика.
- Типы передачи данных. Unicast, Multicast, Broadcast.
- Цифровая подстанция. Потоки в ЛВС и управление ими
- Как данные передаются в сети и зачем управлять multicast-потоками
- Unicast
- Broadcast
- Unknown Unicast
- Multicast
- Краткий ликбез по MAC-адресам
- Суть multicast
- Как это работает в реальной ЛВС
- Типы передачи данных. Что такое цифровая подстанция и зачем там нужен multicast
- Кто участвует в передаче данных
- Какие данные передаются в ЛВС
- Типовая архитектура ЛВС
- Особенности передачи Multicast в цифровой подстанции
- Какие данные передаются с помощью multicast
- Зачем необходим multicast
- Нюансы multicast-передачи в цифровой подстанции
- Нюанс 1. Для GOOSE и SV определены свои multicast-группы
- Нюанс 2. Терминалы не используют протоколы multicast
- Нормативная база
- Заключение
Передача Unicast, Broadcast и Multicast трафика.
Существует три основных метода передачи трафика в IP-сетях, это — Unicast, Broadcast и Multicast.
Понимание разницы между этими методами является очень важным для понимания преимуществ IP-телевидения и для практической организации трансляции видео в IP-сети.
Каждый из этих трех методов передачи использует различные типы назначения IP-адресов в соответствии с их задачами и имеется большая разница в степени их влияния на объем потребляемого трафика.
Unicast трафик (одноцелевая передача пакетов) используется прежде всего для сервисов «персонального» характера. Каждый абонент может запросить персональный видео-контент в произвольное, удобное ему время.
Unicast трафик направляется из одного источника к одному IP-адресу назначения. Этот адрес принадлежит в сети только одному единственному компьютеру или абонентскому STB как показано на рисунке ниже.
Число абонентов, которые могут получать unicast трафик одновременно, ограничено доступной в магистральной части сети шириной потока (скоростью потока). Для случая Gigabit Ethernet сети теоретическая максимальная ширина потока данных может приближаться к 1 Гб/сек за вычетом полосы, необходимой для передачи служебной информации и технологических запасов оборудования. Предположим, что в магистральной части сети мы можем для примера выделить не более половины полосы для сервисов, которым требуется unicast трафик. Легко подсчитать для случая 5Мб/сек на телевизионный канал MPEG2, что число одновременно получающих unicast трафик абонентов не может превышать 100.
Broadcast трафик (широковещательная передача пакетов) использует специальный IP-адрес, чтобы посылать один и тот же поток данных ко всем абонентам данной IP-сети. Например, такой IP-адрес может оканчиваться на 255, например 192.0.2.255, или иметь 255 во всех четырех полях (255.255.255.255).
Важно знать, что broadcastтрафик принимается всеми включенными компьютерами (или STB) в сети независимо от желания пользователя. По этой причине этот вид передачи используется в основном для служебной информации сетевого уровня или для передачи другой исключительно узкополосной информации. Разумеется, для передачи видео-данных broadcast трафик не используется. Пример передачи broadcastтрафика показан на рисунке ниже.
Multicast трафик (групповая передача пакетов) используется для передачи потокового видео, когда необходимо доставить видео-контент неограниченному числу абонентов, не перегружая сеть. Это наиболее часто используемый тип передачи данных в IPTV сетях, когда одну и ту же программу смотрят большое число абонентов.
Multicast трафик использует специальный класс IP-адресов назначения, например адреса в диапазоне 224.0.0.0 ….. 239.255.255.255. Это могут быть IP-адреса класса D.
В отличие от unicast трафика, multicast адреса не могут быть назначены индивидуальным компьютерам (или STB). Когда данные посылаются по одному из multicast IP-адресов, потенциальный приемник данных может принять решение принимать или не принимать их, то есть будет абонент смотреть этот канал или нет. Такой способ передачи означает, что головное оборудование IPTV оператора будет передавать один единственный поток данных по многим адресам назначения. В отличие от случая broadcast передачи, за абонентом остается выбор — принимать данные или нет.
Важно знать, что для реализации multicast передачи в IP-сети должны быть маршрутизаторы, поддерживающие multicast. Маршрутизаторы используют протокол IGMP для отслеживания текущего состояния групп рассылки (а именно, членство в той или иной группе того или иного конечного узла сети).
Основные правила работы протокола IGMP следующие:
— конечный узел сети посылает пакет IGMP типа report для обеспечения запуска процесса подключения к группе рассылки;
— узел не посылает никаких дополнительных пакетов при отключении от группы рассылки;
— маршрутизатор m ulticast через определенные временные интервалы посылает в сеть запросы IGMP. Эти запросы позволяют определить текущее состояние групп рассылки;
— узел посылает ответный пакет IGMP для каждой группы рассылки до тех пор, пока имеется хотя бы один клиент данной группы.
Загрузка магистральной части сети multicast трафиком зависит только от числа транслируемых в сети каналов. В ситуации с Gigabit Ethernet сетью, предположив, что половину магистрального трафика мы можем выделить под multicast передачу, мы получаем около 100 телевизионных MPEG-2 каналов, каждый имеющий скорость потока данных 5 Мб/сек.
Разумеется, в IPTV сети присутствуют одновременно все 3 вида трафика broadcast, multicast и unicast. Оператор, планируя оптимальную величину пропускной способности сети, должен учитывать разный механизм влияния разных технологий IP- адресации на объем трафика. Например, оператор должен ясно представлять себе, что предоставление услуги «видео на заказ» большому числу абонентов требует очень высокой пропускной способности магистральной сети. Одним из решений этой проблемы является децентрализация в сети видео-серверов. В этом случае центральный видео-сервер заменяется на несколько локальных серверов, разнесенных между собой и приближенных к периферийным сегментам многоуровневой иерархической архитектуры IP-сети.
Типы передачи данных. Unicast, Multicast, Broadcast.
Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.
В unicast пакетах в качестве IP адреса назначения используется конкретный IP адрес устройства, для которого этот пакет предназначен. IP адрес конкретного устройства состоит из порции адреса сети (в которой находится это устройство) и порции адреса хоста (порции, определяющей это конкретное устойчиво в его сети). Это все приводит к возможности маршрутизации unicast пакетов по всей сети.
Multicast и broadcast пакеты, в отличие от unicast пакетов, имеют свои собственные специальные (зарезервированные) IP адреса для использования их в заголовке пакетов в качестве пункта назначения. Из-за этого, broadcast пакеты в основном ограничены пределами локальной сети. Multicast трафик также может быть ограничен границами локальной сети, но с другой стороны также может и маршрутизироваться между сетями.
В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.
В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).
Тип передачи multicast разрабатывался для сбережения пропускной способности в IP сетях. Такой тип уменьшает трафик, позволяя хостам отправить один пакет выбранной группе хостов. Для достижения нескольких хостов назначения используя передачу данных unicast, хосту источнику было бы необходимо отправить каждому хосту назначения один и тот же пакет. С типом передачи данных multicast, хост источник может отправить всего один пакет, который может достичь тысячи хостов получателей.
Примеры multicast передачи данных:
> видео и аудио рассылка
> обмен информацией о маршрутах, используемый в маршрутизируемых протоколах.
> распространение программного обеспечения
> ленты новостей
Хосты, которые хотят получить определенные multicast данные, называются multicast клиентами. Multicast клиенты используют сервисы инициированные (начатые) клиентскими программами для рассылки multicast данных группам.
Каждая multicast группа представляет собой один multicast IP адрес назначения. Когда хост рассылает данные для multicast группы, хост помещает multicast IP адрес в заголовок пакета (в раздел пункта назначения).
Для multicast групп выделен специальный блок IP адресов, от 224.0.0.0 до 239.255.255.255.
Из-за того, что тип передачи broadcast используется для отправки пакетов ко всем хостам в сети, пакеты использую специальный broadcast IP адрес. Когда хост получает пакет, в заголовке которого в качестве адреса получателя указан broadcast адрес, он обрабатывает пакет так, как будто это unicast пакет.
Когда хосту необходимо передать какую-то информацию всем хостам в сети используется способ передачи данных broadcast. Еще когда адрес специальных сервисов (служб) или устройств заранее неизвестен, то для обнаружения также используется broadcast (широковещание).
Примеры, когда используется broadcast передача данных:
> создание карты принадлежности адресов верхнего уровня к нижним (например, какой IP адрес на конкретном устройстве со своим MAC адресом)
> запрос адреса (в качестве примера можно взять протокол ARP)
> протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)
Когда хосту нужна информация, он отправляет запрос на широковещательный адрес. Все остальные хосты в сети получат и обработают этот запрос. Один или несколько хостов вложат запрашиваемую информацию и ответят на запрос. В качестве типа передачи данных, отвечающие на запрос будут использовать unicast.
Подобным образом, когда хосту необходимо отправить информацию всем хостам в сети, он создаёт широковещательный пакет с его информацией и передаёт его в сеть.
В отличие от unicast передачи, где пакеты могут быть маршрутизированы через всю сеть, broadcast пакеты, как правило, ограничиваются локальной сетью. Это ограничение зависит от настройки маршрутизатора, который ограничивает сеть и следит за типом широковещания (broadcast).
Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.
Направленный broadcast отправляется всем хостам какой-то конкретной сети. Этот тип широковещания удобно использовать для отправки broadcast трафика всем хостам за пределами локальной сети.
Например, хост хочет отправить пакет всем хостам в сети 172.16.5.0/24, но сам хост находится в другой сети. В данном случае хост-отправитель вложит в заголовок пакета в качестве адреса пункта назначения broadcast адрес 172.16.5.255. Хотя маршрутизаторы должны ограничивать (не передавать) направленный широковещательный трафик, их можно настроить на разрешение передачи broadcast трафика.
Ограниченный broadcast используется для передачи данных всем хостам в локальной сети. В такие пакеты в качестве пункта назначения вставляется IP адрес 255.255.255.255. Маршрутизаторы такой широковещательный трафик не передают. Пакеты, переданные ограниченным broadcast будут распространяться только в локальной сети. По этой причине локальные сети IP также называют широковещательным доменом (broadcast domain). Маршрутизаторы образуют границу для широковещательного домена. Без границы пакеты бы распространялись по всей сети, каждому хосту, уменьшая быстродействие сетевых устройств и забивая пропускную способность каналов связи.
Приведу пример ограниченного broadcast: хост находится внутри сети 172.16.5.0/24 и хочет передать пакет всем хостам в его сети. Используя в качестве пункта назначения IP адрес 255.255.255.255, он отправляет широковещательный пакет. Этот пакет примут и обработают все хосты только в этой локальной сети (172.16.5.0/24).скачать dle 12.0
Цифровая подстанция. Потоки в ЛВС и управление ими
Цифровая подстанция — это тренд в энергетике. Если вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?
Как данные передаются в сети и зачем управлять multicast-потоками
Прежде чем переходить непосредственно к цифровой подстанции и нюансам построения ЛВС, предлагаем краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками.
Существует четыре типа передачи данных:
- 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-адрес виртуальный. То есть принадлежит не реальному физическому устройству, а виртуальной группе.
Виртуальную группу можно сравнить с вышкой радиовещания. Радиокомпания транслирует на эту вышку какую-то музыку, а те, кому хочется ее послушать, — настраивают приемники на нужную частоту. Также, например, IP-видеокамера отправляет данные в виртуальную группу, а те устройства, которые хотят эти данные получать, подключаются к этой группе.
Восьмой бит первого октета MAC-адреса
Если на коммутаторе не включена поддержка multicast, то он будет 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-адреса для рассылки.
Типы передачи данных. Что такое цифровая подстанция и зачем там нужен 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 — 0×88b8. Это обеспечивает высокую скорость передачи данных. Теперь необходимо закрыть требования гарантированности и надежности.
Очевидно, что для гарантированности необходимо понимать доставлено ли сообщение, но мы не можем организовать отправки подтверждений получения, как, например, это делается в TCP. Это значительно снизит скорость передачи данных. Поэтому для передачи GOOSE используется архитектура «издатель-подписчик».
Архитектура «издатель-подписчик»
Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом — через чуть больший и так далее. В итоге время увеличивается до Т0.
Принцип передачи GOOSE-сообщений
Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке. SV-потоки также передаются на канальном уровне, имеют свой Ethertype — 0×88BA и передаются по модели «издатель-подписчик».
Нюансы 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 регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.