Широковещательные сообщения что это

Подключение микроконтроллера к локальной сети: Широковещательные сообщения и DHCP

В этой части мы поговрим про широковещательные сообщения и, наконец-то, закончим с UDP.

Широковещательные сообщения

Иногда бывает полезно отправить сообщение сразу всем узлам локальной сети. Например, если к сети подключено несколько девайсов и хочется обратиться сразу ко всем. Особенно, если адреса девайсов неизвестны.

Для широковещательных пакетов используется последний адрес подсети. Скажем, для подсети 192.168.0.0 с маской 255.255.255.0 широковещательный адрес — 192.168.0.255.

Пакет, отправленный на этот адрес придёт всем узлам, подключенным к подсети и поддерживающим широковещательные пакеты.

Можно ли отправить широковещательный пакет в чужую подсеть? Теоретически да, но на деле наш пакет никому там не нужен. Любой приличный роутер встретив такой пакет, незадумываясь его грохнет.

Также, существует «широковещательный адрес для всего интернета» 255.255.255.255. Но чаще всего, этот адрес просто считается невалидным. В форточках он даже юзается в качестве индикатора ошибки (в возвращаемых значениях, etc.)

Пишем поддержку широковещательных сообщений

Чтобы научить наш стек отправлять и принимать широковещательные сообщения, достаточно дописать всего несколько строчек кода.

Во-первых, определим сам широковещательный адрес для нашей сети:

Теперь можно посылать широковещательный пинг и смотреть как девайс(ы) на него отзываются)

До этого момента мы прописывали IP-адрес и другие параметры, нужные для работы в сети в явном виде. Что очень неудобно — требуется отдельно конфигурировать каждый девайс перед использованием. Совершенно не годится если ты захочешь, например, подарить кому-нибудь готовый девайс.

К счастью, существует специальный протокол DHCP (Dynamic Host Configuration Protocol), основанный на широковещательных сообщениях, позволяющий узлу все нужные для конфигурирования самого себя данные получить с работающего в сети DHCP-сервера.

DHCP-сервер есть почти во всех сетях. В домашних роутерах он, как правило, включен по умолчанию, etc. То, что нужно!

Вот, в кратце, алгоритм получения узлом конфигурационных данных:

Если DHCP-сервер вдруг перестанет работать, узел может попробовать найти другой DHCP-сервер и запросить у него такой же адрес.

Если срок использования IP-адреса истечёт (и продлить его не удасться), узел возвращается в исходное состояние и пробует снова найти DHCP-сервер и выделить адрес.

DHCP несколько тяжёлый протокол для МК. Но и пользы от него немало. Можно немножко облегчить DHCP — оставить только функцию получения конфигурационных параметров и функцию, повторяющую запрос через определённый интервал.

Формат пакета DHCP:

DHCP является расширенной версией протокола загрузки по сети BOOTP, и формат пакета в общем-то унсаледован от него. Так что почти вся полезная информация лежит в опциях.

Между опциями могут вставляться нули для выравнивания опций на 2 байта. После всех опций вставляется байт 0xff — индикатор конца поля.

В общем, всё понятно из кода

В коде встречаются псевдофункции gettc() и rtime() — они возвращают, соответственно количество милисекунд и секунд с момента включения питания. Удобно для отсчёта различных интервалов.

Запросы на выделение адреса отправляются на адрес 255.255.255.255. Пока хост не сконфигурирован (IP-адрес и маска = 0.0.0.0) этот адрес и служит широковещательным.

Основная прошивка девайса должна учитывать, что отправлять пакеты можно только после того, как адрес будет получен.

Ещё один момент — по хорошему нам нужно следить за состоянием линка. При втыкании провода нужно обновлять адрес.

Вот пример использования:

Заключение

Заходим на роутер и, обновляя страничку, палим в реальном времени как девайс получает и обновляет адрес по DHCP.

Время выделения адреса я для прикола установил в 2 минуты.

Конечно DHCP немного тяжеловат для МК (моя реализация отожрала больше 2 КБ прошивки). Зато избавляет от необходимости настраивать девайс вручную, что тоже довольно ценно.

Итак, про UDP на этом всё.

В следующий раз будет обещаная статья про связь с компом. А потом перейдём к самому интересному)

Источник

Широковещательная передача сообщений

Широковещательные сообщения

Когда отправляется пакет всем узлам сети, его называют — широковещательным пакетом и он имеет специальные широковещательный адрес. При получении такого пакета, узел анализирует широковещательный адрес и понимает, что он является адресом назначения. И так думает каждый узел в сети.

Широковещательная передача отлично подходит для адресатов с неизвестными адресами разных устройств и служб, или же когда нужно передать информацию всем участникам сети. Ниже наведены примеры реализации широковещательных сообщений:

Когда участник сети требует информацию, он отправляет запрос на широковещательный адрес. Все узлы принимают и обрабатывают этот запрос. Те узлы которые имеют данные отправляют пакет в ответ уже через одноадресную передачу. Если одноадресная передача может передавать пакеты за границы сети, то широковещательные пакеты не передаются за пределы локальной сети. Это зависит от маршрутизатора. Есть два вида широковещательных сообщений: направленная и ограниченная.

Направленная широковещательная передача

Направленная широковещательная передача может передавать пакеты всем узлам любой одной сети. Можно отправлять пакеты за пределы своей сети в другую. Если узлу нужно передать пакеты всем узлам сети 171.15.5.0/24, то он пишет адрес пакеты назначения — 171.15.5.255. Хоть и по умолчанию маршрутизаторы не реализуют такую функцию, их можно настроить для такой передачи.

Ограниченная широковещательная передача

Ограниченная широковещательная передача реализуется для коммуникации, которая ограничена одной локальной сетью. Пакеты используют адрес — IPv4 255.255.255.255 и маршрутизаторы такие пакеты не выпустят из локальной сети 🙂

Широковещательный трафик сильно захламляет сеть, так как каждый узел должен обработать широковещательный пакет. Зачастую ограничивают или разделяют широковещательный трафик для улучшения производительности сети.

Источник

Широковещательные сообщения

Поскольку широковещательный сообщения используются для отправки пакетов всем узлам в сети, пакет использует специальный широковещательный адрес. Когда узел получает пакет с широковещательным адресом в качестве адреса назначения, он обрабатывает пакет, как будто бы этот пакет предназначался для его индивидуального адреса.

Широковещательная передача используется для обнаружения специальных служб/устройств, для которых адрес не известен, или когда узел должен передать информацию всем узлам в сети.

Некоторые примеры использования широковещательных сообщений:

Когда узел нуждается в информации, он отправляет запрос на широковещательный адрес. Все узлы в сети получают и обрабатывают этот запрос. Один или более узлов с требуемой информацией отвечают, обычно используя одноадресную передачу.

Точно так же, когда узел должен отправить информацию всем узлам в сети, он создает и отправляет широковещательный пакет с этой информацией.

В отличие от одноадресной передачи, где пакеты могут быть направлены куда-угодно в объединенной сети, широковещательные пакеты обычно не могут выйти за пределы локальной сети. Это ограничение зависит от конфигурации маршрутизатора, который ограничивает сеть, а также от типа широковещательной передачи. Есть два типа широковещательных сообщений: направленная широковещательная передача и ограниченная широковещательная передача.

Направленная Широковещательная передача

Ограниченная Широковещательная передача

К примеру, узел внутри сети 172.16.4.0 / 24 может передать широковещательное сообщение ко всем узлам в своей сети, используя пакет с адресом получателя 255.255.255.255.

На рисунке представлен пример отправки широковещательного сообщения.

Как Вы узнали ранее, когда пакет передается широковещательно, он использует сетевые ресурсы, а также заставляет каждый узел в сети, который его получает, обработывать пакет. Поэтому, широковещательный трафик должен быть ограничен так, чтобы он не оказал негативное влияние на производительность сети или устройств. Поскольку маршрутизаторы отделяют широковещательные домены, разбиение сети с чрезмерным широковещательным трафиком на подсети может улучшить производительность сети.

Источник

Broadcast (Широковещательные сообщения)

Практическая часть показана в отдельной статье.

Широковещательные сообщения делают приложение более открытым; передавая события, использующие сообщения, вы открываете компоненты своего приложения для сторонних приложений, и сторонние разработчики реагируют на события без необходимости изменять ваше оригинальное приложение. В своём приложении вы можете прослушивать широковещательные сообщения других приложений, заменить или улучшить функциональность собственного (или стороннего) приложения или реагировать на системные изменения и события приложений.

Вы тоже можете организовать отправку широковещательных сообщений, а другие приложения могут обзавестись приёмниками для обработки ваших сообщений.

Приёмник широковещательных сообщений — это компонент для получения внешних событий и реакции на них. Инициализировать передачи могут:

Широковещательные сообщения можно разделить на две группы:

Класс BroadcastReceiver является базовым для класса, в котором должны происходить получение и обработка сообщений, посылаемых клиентским приложением с помощью вызова метода sendBroadcast().

Зарегистрировать экземпляр класса BroadcastReceiver можно динамически в коде или статически в манифесте.

Для статической регистрации в файле манифеста в секции application следует создать секцию receiver и указать класс приёмника. Атрибут android:exported=»true» сообщает получателю, что он может принимать широковещательные сообщения вне области приложения. Внутри секции указывается фильтр намерений в виде строки, чтобы определить, какие сообщения приёмник должен прослушивать.

Если регистрация была сделана через манифест, приложение не обязано работать, чтобы ваш приёмник среагировал на трансляцию намерения. Приложение запустится автоматически, когда подходящие намерение будет транслировано. Система сама сканирует содержимое манифеста всех приложений и делает за нас всю работу. Это хорошее решение, позволяющее экономить ресурсы. Такой подход позволяет создавать приложения, способные реагировать на события даже после завершения или принудительного завершения.

Динамическая регистрация происходит с помощью метода Context.registerReceiver().

Перед этим создаётся класс, расширяющий базовый класс BroadcastReceiver и реализуется метод обратного вызова onReceive() обработчика событий.

Метод onReceive() будет выполнен при получении широковещательного намерения, если полученное намерение соответствует фильтру. Приложения с зарегистрированными приёмниками широковещательных намерений будут запущены автоматически при получении соответствующего намерения. Метод должен быть завершён в течение пяти секунд, иначе появится диалоговое окно о принудительном закрытии.

Когда широковещательное сообщение прибывает для получателя сообщения, Android вызывает его методом onReceive() и передаёт в него объект Intent, содержащий сообщение. Приёмник широковещательных сообщений является активным только во время выполнения этого метода. Процесс, который в настоящее время выполняет BroadcastReceiver, т. е. выполняющийся в настоящее время код в методе обратного вызова onReceive(), как полагает система, является приоритетным процессом и будет сохранён, кроме случаев критического недостатка памяти в системе.

Когда программа возвращается из метода onReceive(), приёмник становится неактивным и система полагает, что работа объекта BroadcastReceiver закончена. Процесс с активным широковещательным получателем защищён от уничтожения системой. Однако процесс, содержащий неактивные компоненты, может быть уничтожен системой в любое время, когда память, которую он потребляет, будет необходима другим процессам.

Это представляет проблему, когда ответ на широковещательное сообщение занимает длительное время. Если метод onReceive() порождает отдельный поток, а затем возвращает управление, то полный процесс, включая и порождённый поток, система Android считает неактивным (если другие компоненты приложения не активны в процессе), и считает этот процесс кандидатом на уничтожение.

В частности, вы не можете отобразить диалог или осуществить связывание со службой внутри экземпляра BroadcastReceiver. Для первого случая необходимо вместо этого использовать методы класса NotificationManager. Во втором случае можно использовать вызов метода Context.startService(), чтобы послать команду для запуска службы.

Решение этой проблемы возможно, если запустить в методе onReceive() отдельную службу вместе с BroadcastReceiver и позволить службе выполнять задание, чтобы сохранить содержание процесса активным в течение всего времени вашей операции.

Также можно зарегистрировать широковещательный приёмник не через манифест, а программно. Приёмник, зарегистрированный таким способом, будет отвечать на поступающие намерения только в том случае, если компонент приложения, которому он принадлежит, выполняется в этот момент.

Это может быть полезным, когда приёмник используется для обновления элементов пользовательского интерфейса внутри активности, запуска служб или уведомления через NotificationManager. В таких случаях вы можете отменять регистрацию широковещательного приёмника, если активность не отображается на экране или находится в неактивном состоянии.

В коде программы можете написать приблизительно такой код (обычно используют метод onResume()):

Для отмены регистрации используется метод unregisterReceiver() в контексте приложения, передавая ему в качестве параметра экземпляр широковещательного приёмника (обычно в методе onPause()):

Для объекта BroadcastReceiver нет никаких возможностей видеть или фиксировать намерения, используемые в методе startActivity(). Аналогично, когда вы передали намерение для запуска активности через объект BroadcastReceiver, вы не сможете найти или запустить требуемую активность. Эти две операции семантически полностью различаются: запуск активности через намерение является приоритетной операцией для системы, изменяющей содержимое экрана устройства, с которым в настоящее время взаимодействует пользователь. Передача широковещательных сообщений для системы является фоновой работой, о которой обычно не знает пользователь и которая, соответственно, имеет более низкий приоритет.

Приёмники системных событий

Android использует широковещательные сообщения для системных событий, таких как уровень зарядки батареи, сетевые подключения, входящие звонки, изменения часового пояса, состояние подключения данных, входящие сообщения SMS или обращения по телефону. Вы можете использовать эти сообщения, чтобы добавлять к вашим собственным проектам новые функциональные возможности, основанные на системных событиях.

Следующий список показывает некоторые из встроенных действий, представленных как константы в классе Intent, которые используются для того, чтобы проследить изменения состояния устройства:

Типы трансляций

Есть три способа отправки трансляций

Если важно, чтобы приёмники получали намерения в определённом порядке или могли влиять на транслируемое намерение, можно использовать метод sendOrderedBroadcast():

С помощью этого метода ваше намерение дойдёт до всех зарегистрированных приёмников, обладающих необходимым доступом (если он был указан), в порядке их приоритета. Приоритет задаётся с помощью атрибута android:priority внутри узла фильтра намерений в манифесте. Чем больше значение, тем выше приоритет.

Производить упорядоченные трансляции с использованием приоритетов рекомендуется только для тех приёмников, которым необходим конкретный порядок приёма сообщений.

Ограничения в Android 8.0 Oreo (API 26)

Часть неявных (implicit) широковещательных сообщений, задаваемых через манифест, запретили. Теперь нужно регистрировать их программно. Существует список исключений, которые будут работать как прежде без ограничений.

В качестве замены для некоторых случаев подойдёт JobScheduler.

Примерами устаревшего способа работы с приёмником является android.net.conn.CONNECTIVITY_CHANGE, ACTION_POWER_CONNECTED и др.

Ограничения в Android 9.0 Pie (API 28)

Стало доступно меньше информации, получаемой при трансляции системы Wi-Fi и Network_State_Changed_Action.

Источник

Как управлять потоками в ЛВС Цифровой Подстанции?

Цифровая Подстанция – это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?

Всем, кому интересно разобраться в этой теме, – welcome под кат!

Как данные передаются в сети и зачем управлять 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.

Передача 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 запоминает, на какой порт приходит multicast-поток. Подписчики должны отправить IMGP Join сообщение для подключения к группе. Коммутатор добавляет порт, с которого пришел IGMP Join, в список нисходящих интерфейсов и начинает передавать multicast-поток туда. Коммутатор постоянно посылает IGMP Query сообщения на нисходящие порты, чтобы проверить, нужно ли продолжать передавать данные. Если с порта пришло сообщение IGMP Leave или не было ответа на сообщение IGMP Query, то вещание на него прекращается.

У протокола PIM есть две реализации:

PIM SM по принципу работы близко к IGMP.

Если очень грубо обобщить общий принцип работы multicast – Издатель отправляет multicast-поток на определенную MAC-группу, подписчики отправляют запросы на подключение к этой группе, коммутаторы управляют данными потоками.

Почему мы настолько поверхностно прошлись по multicast? Давайте поговорим про специфику ЛВС Цифровой Подстанции, чтобы понять это.

UPD: Протоколы IGMP и PIM — это протоколы сетевого уровня и они работают с IP-адресами. При передаче данных IP-группа транслируется в MAC-адрес. Подробнее про это можно посмотреть, например, здесь. Есть протоколы, которые используют только MAC-адреса для рассылки (подробнее).

Что такое Цифровая Подстанция и зачем там нужен multicast?

Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:

Что такое Цифровая Подстанция?

Цифровая Подстанция – это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.

Соответственно, в цифровом виде здесь передаются все данные:

Цифровая подстанция — автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.

Кто участвует в передаче данных?

В составе Цифровой Подстанции есть следующие системы:

Какие данные передаются в ЛВС?

Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина – это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.

Структурная схема электроэнергетического объекта в соответствии с МЭК 61850

На структурной схеме изображены шины:

Через шину «Передача сигналов РЗА» терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.

Через шину «Передача мгновенных значений напряжений и токов» реализована передача измерений. К этой шине подключаются устройства измерения – трансформаторы тока и напряжения, а также терминалы релейной защиты.

Также к шине «Передача мгновенных значений напряжений и токов» подключается сервер АСКУЭ, который также забирает к себе измерения для учета.

А шина «Мониторинг/Управление» служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.

С сервера АСУ ТП данные отправляются в диспетчерский пункт.

Какая типовая архитектура ЛВС?

Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.

На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.

Архитектура Цифровой Подстанции

На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.

Архитектура разбита на три уровня:

Уровень присоединения включает в себя все технологическое оборудование.

Уровень процесса включает в себя измерительное оборудование.

Также есть две шины для объединения уровней:

Особенности передачи Multicast в Цифровой Подстанции

Какие данные передаются с помощью multicast?

Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры «Издатель-Подписчик». Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.

До цифровой подстанции в энергетике горизонтальная связь реализовывалась при помощи связи точка-точка между терминалами. В качестве интерфейса использовался либо медный, либо оптический кабель. Данные передавались по проприетарным протоколам.

К этой связи предъявлялись очень высокие требования, т.к. по этим каналам передавали сигналы срабатывания защит, положения коммутационных аппаратов и т.д. От этой информации зависел алгоритм оперативной блокировки терминалов.

В случае если данные будут передавать медленно или негарантированно, велика вероятность, что какой-то из терминалов не получит актуальной информации по текущей ситуации и может подать сигнал на отключение или включение коммутационного аппарата, когда на нем, например, будут проводиться какие-то работы. Или УРОВ не отработает вовремя и КЗ распространится на остальные части электрической схемы. Все это чревато большими денежными потерями и угрозой человеческой жизни.

Поэтому данные должны были передаваться:

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? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:

Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое 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 регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.

Источник