Sv поток 61850 что это

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

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

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

Как данные передаются в сети и зачем управлять multicast-потоками?

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

Типы передачи данных

Типы траффика в ЛВС

Существует четыре типа передачи данных:

Broadcast – широковещательная рассылка.
Unicast – обмен сообщениями между двумя устройствами.
Multicast – рассылка сообщений на определенную группу устройств.
Unknown Unicast – широковещательная рассылка с целью найти одно устройство.

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

СТО 34.01-21-004-2019 — ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВЫХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВЫХ ЦИФРОВЫХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
СТО 34.01-6-005-2019 — КОММУТАТОРЫ ЭНЕРГООБЪЕКТОВ. Общие технические требования.
СТО 56947007-29.240.10.302-2020 — Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.

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

Полезные ссылки:

цифровая подстанция
лвс
предача данных
управление потоками
Multicast
энергетика
multicast-потоки
протоколы передачи данных

Блог компании ООО «НПО «АвалонЭлектроТех»
Сетевые технологии
Сетевое оборудование

Моделируем кибератаки на энергосистемы и пытаемся разобраться с «гусями» в сети

Ryan GOOSling

Привет, Хабр! Когда‑то у нас выходил материал по применению протокола SV на электроэнергетических объектах, в котором мы обещали разбор протокола GOOSE. Итак, время пришло.

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

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

Что за GOOSE

Для начала немного теории. Если мы обратимся к корпоративному профилю МЭК 61 850 ПАО «ФСК ЕЭС», то протокол GOOSE (Generic Object — Oriented Substation Event) используется для быстрой передачи данных о событиях между интеллектуальными электронными устройствами по локальной вычислительной сети. Под интеллектуальными электронными устройствами (ИЭУ) понимаются терминалы РЗА, контроллеры присоединений (КП), преобразователи дискретных сигналов (ПДС), некоторые измерительные устройства. Фактически данный протокол служит для замены медных кабельных связей, предназначенных для передачи дискретных (но не обязательно) сигналов между устройствами. Под событиями в определении понимаются срабатывания и пуски устройств РЗА, изменения положения коммутационного оборудования и так далее. Даже измерения с датчика температур для работы противоаварийной автоматики можно передать через GOOSE, так как не требуется такой большой частоты передачи измерений, как для тока или напряжения по SV.

Связи ИЭУ между собой

Процесс передачи GOOSE

Раз мы упомянули про частоту передачи сообщений, то нужно пояснить, как идет процесс обмена сообщениями. Обмен сообщениями происходит по ЛВС — в стандартной архитектуре это шина станции/подстанции и на канальном уровне, что обеспечивает высокую скорость передачи данных. Устройства общаются с помощью механизма «Издатель — Подписчик», то есть используют multicast‑потоки.

Устройство‑издатель отправляет GOOSE‑сообщение на шину, а подписчики его получают, причем получают все устройства в сети (или виртуальной сети, но об этом чуть позже), а не только подписанные. По сути, устройства принимают все сообщения, но обрабатывают только те, на которые подписаны, остальные отбрасываются.

Сами сообщения передаются в нормальном режиме с постоянным интервалом времени Т0, который измеряется в секундах и может быть достаточно большим. То есть поток GOOSE‑сообщений постоянно передает набор данных, отражающий состояние устройства и контролируемого оборудования. Например, устройство РЗА передает состояние сигнала срабатывания, которое равно логическому 0 в нормальном режиме. Далее рассмотрим процесс передачи сообщений, как это описано в МЭК 61 850–8–1. Как только происходит событие, например короткое замыкание с последующей работой защит с изменением передаваемых данных в потоке GOOSE‑сообщений с 0 на 1, происходит отправка нового сообщения в независимости от того, закончился период Т0 или нет. Следующие сообщения приходят с минимальным интервалом передачи Т1, который с последующими сообщениями увеличивается до Т2 и Т3, пока не придет к значению Т0. Тот же процесс повторится при изменении с 1 на 0 того же сигнала.

Механизм циклической передачи GOOSE-сообщений

Временные интервалы и количество сообщений являются настраиваемыми параметрами. Например, по корпоративному профилю МЭК 61850 ПАО «ФСК ЕЭС» после сообщения при возникновения события идет еще четыре с минимальным временем, а затем до восстановления нормального режима генерируются еще три сообщения с увеличением интервала в два раза.

Передача GOOSE-сообщений по стандарту ФСК

С помощью такого увеличения генерации сообщений во время событий обеспечивает гарантированную доставку сообщений. Если же сообщения не приходят слишком долго, дольше интервала timeAllowedToLive, значение которого хранится в последнем принятом GOOSE, то устройства сигнализирует об отсутствии сообщений. Учитывая все вышеописанное, получаем быструю и надежную передачу данных, конечно, при условии грамотной организации связи.

Как выглядит GOOSE-сообщение

Для передачи GOOSE-сообщений используются формат фрейма Ethernet II. Само сообщение может быть довольно большим и содержать разную информацию, не только логические сигналы от устройств.

Структура кадра

Итак, начнем разбор полей по порядку с самого начала кадра.

Поля канального уровня:

Preamble длиной 8 байт находится в самом начале Ethernet кадра. Преамбула сообщает получателю о необходимости подготовиться к поступлению кадра.

Destination Address длиной 6 байт содержит MAC-адрес получателя. Как раз этот адрес определяет используемый в GOOSE режим многоадресной рассылки-multicast. Для данного поля используется стандартизованный диапазон адресов в рамках одного объекта 01:0C:CD:01:00:00-01:0C:CD:01:01:FF, однако он может быть расширен до 01:0C:CD:01:03:FF.

Структура МАС-адреса

Source Address длиной 6 байт содержит MAC-адрес отправителя, то есть устройства – источника сообщений.

Priority tagging/Virtual LAN длиной 4 байта для разметки приоритета в соответствии с IEEE 802.1Q. Используется для разделения критического по времени и высокоприоритетного трафика шины от низкоприоритетной нагрузки на шину. А также деления нашей шина на виртуальные для управления трафиком.

Поле TPID (Tag Protocol Identifier) указывает тип Ethertype, назначенный для кадров типа Ethernet 802.1Q и должно быть равно 0x8100.

Поле TCI (Tag Control Information) состоящее из: User Priority – того самого приоритета, который равен значению 4 (GOOSE и SV – крайне важная информация и трафик с высоким приоритетом), CFI – флаг канонического формата и равен 0, VID – идентификатор виртуальной сети.

Ethertype длиной 2 байта указывает тип протокола (0x88b8 для GOOSE).

APPID длиной 2 байта – идентификатор приложения – для выбора кадров, содержащих GOOSE. Диапазон зарезервированных значений для GOOSE Type 1 составляет от 0x0000 до 0x3FFF, для GOOSE Type 1A диапазон зарезервированных значений составляет от 0x8000 до 0xBFFF. Про классификацию сообщений можно подробнее почитать в МЭК61850-8-2 или ПАО «ФСК ЕЭС».

Length длиной 2 байта содержит значение количества байт, начиная с поля APPID до конца блока APDU.

Reserved 1 длиной 2 байта содержит S (simulated) бит, устройство в режиме теста, когда равен 1, три R бита, зарезервированных для будущего и двенадцать зарезервированных битов безопасности, которые должны использоваться, когда передается GOOSE с защитой, в противном случае он должен быть установлен в 0.

Reserved 2 длиной 2 байта полностью зарезервирован под безопасность.

Frame check sequence длиной 4 байта со значением контрольной суммы для проверки целостности данных при передаче.

Поля прикладного уровня

Тут нужно сделать небольшое отступление и дать объяснение тому, как кодируются дальнейшие поля в APDU. Все поле – это набор байт, где первый байт это Tag или Тип, далее идут байты со значением длины (Length) полезной информации в триплете, а затем и сами полезные данные (Value). Value тоже в свою очередь может быть триплетом.

Правила кодирования

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

Правила кодировки разных типов данных в поле allData

Итак, кодируя число 127 формата INT32U, мы можем использовать фиксированный вариант кодировки и получим триплет 0x86 0x05 0x00 0x00 0x00 0x00 0x7f, а можем использовать плавающую длину и получить триплет 0x86 0x01 0x7f. При этом информация останется одной и той же. И тот и другой способ имеет свое применение.

Перейдем к нашим полям (кстати, их длина указана на диаграмме сверху):

goCBRef — ссылка на блок управления GOOSE — это уникальное имя пути к экземпляру блока управления GOOSE (goCB) в узле LLN0. Формат — LDName/LLN0.GoCBName, например, GEDeviceF650/LLN0gcb01, где имя LD — GEDeviceF650, класс LN — LLN0 (нулевой логический узел), функциональное ограничение — GO (управление GOOSE), а экземпляр goCB — gcb01. Длина поля может быть разной в зависимости от конфигурации.

timeAllowedtoLive – информирует подписчиков о том, как долго ждать следующего повторения сообщения.

datSet – ссылки на набор данных, значения элементов которого необходимо передать, например, GEDeviceF650/LLN0$GOOSE1. Длина поля может быть разной в зависимости от конфигурации.

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

t – время, когда атрибут stNum был увеличен.

stNum (номер состояния) — это счетчик, который увеличивается каждый раз, когда обнаруживается изменение значения в наборе данных. Начальное значение должно быть 1. Значение 0 зарезервировано.

sqNum – текущий порядковый номер отчетов. Он должен увеличиваться каждый раз при отправке сообщения GOOSE. После изменения stNum счетчик sqNum должен быть установлен на значение 0. Начальное значение для sqNum при передаче равно 1.

simulation – если оно истинно, сообщение и, следовательно, его значение были выданы модулем моделирования и не являются реальными значениями.

confRev — содержит версию конфигурации, указывающую на удаление члена набора данных или изменение порядка элементов или изменение ссылки на datSet. Число должно представлять количество раз, когда конфигурация набора данных, на которую ссылается значение datSet, была изменена.

ndsCom – указывает в сообщении, что требуется некоторая пуско-наладка. Если TRUE – требует дальнейшей настройки.

numDatSetEntries – количество элементов в наборе данных.

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

Передаваемая информация в триплете allData кодируется в дочерние триплеты по вышеупомянутым правилам. Также информация может кодироваться в триплет структуры с тегом 0ха2, в такой структуре кодируется разная информация об одном сигнале, например логический сигнал срабатывания и атрибут качества этого сигнала.

Примеры GOOSE-сообщений

Моделирование GOOSE-спуфинга

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

С развитием цифровых технологий в электроэнергетике возникает все больше возможных сценариев для возникновения киберинцидентов на объектах электроэнергетики. Сейчас эта тема особенно актуальна, так как подобные угрозы затрагивающие системы защиты и автоматики, могут повлечь серьезные последствия для оборудования, людей и энергосистемы в целом. Для изучения возможных механизмов создания угроз электроэнергетической инфраструктуре и ускорения разработки программных и аппаратных средств выявления, защиты и анализа необходимы современные инструменты для моделирования. Ими являются программно-аппаратные комплексы моделирования в реальном времени, например, российский КПМ РИТМ.

Такие комплексы являются инструментом для создания цифровых двойников различных объектов, например, цифровых подстанций, которые могут работать в жестком реальном времени. В подобных комплексах возможно моделировать как «физическую» часть объекта со всем первичным и вторичным оборудованием, так и информационную часть с учетом обмена данными между вторичными устройствами. Таким образом в КПМ РИТМ можно моделировать и запускать в реальном времени модели силового оборудования, логику работы вторичных устройств и информационный обмен. Также комплекс обладает интерфейсами для связи с внешними устройствами, такими как терминалы релейной защиты и автоматики.

Для проведения моделирования GOOSE-спуфинг атаки на терминал РЗА в нашей лаборатории был собран испытательный стенд на базе КПМ РИТМ:

Принципиальная схема стенда А так выглядит вживую

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

Модель энергосистемы собрана в MATLAB/Simulink из блоков библиотеки Simscape Power Systems. Наши испытуемые терминалы защищают линию Л2 и получают с ее конца измерения тока и напряжения. Данные измерения с помощью интерфейса ЦАП передаются на усилитель и идут к терминалам. Также в модели реализован прием сигнала срабатывания через «сухой» контакт, который идет на изменение положения выключателя в модели. При этом в терминал управления выключателем приходит сигнал положения выключателя из модели. Дополнительно в модель добавлены функции АПВ и защиты противоположного конца рассматриваемой линии электропередачи.

Модель энергосистемы

Для моделирования GOOSE-спуфинга в модель были добавлены специальные блоки для перехвата и подмены GOOSE-трафика. Эти блоки были специально разработаны для совместной работы с РИТМ и MATLAB/Simulink, с помощью них и платы Ethernet комплекса можно принимать и раскодировать трафик, а затем составлять GOOSE-сообщения для отправки в сеть.

Блоки для моделирования GOOSE-спуфинга

В рамках опыта смоделируем GOOSE-спуфинг атаку на терминал управления выключателем и сделаем три несложных сценария:

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

Для удобства будем отслеживать трафик в шине процесса с помощью Wireshark, а процессы в сети будем наблюдать цифровыми осциллографами в модели и на терминалах.

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

Опыт КЗ без спуфинга

Спуфинг активируется по команде в модели, в этот момент происходит перехват трафика, его подмена и отправка ложно трафика в сеть параллельно настоящему. При этом в ложном трафике идет увеличение значения поля stNum (помним по теории), таким образом ложный трафик становится более актуальным для терминала, чем настоящий. В таком случае при возникновении КЗ в сети терминал дистанционной защиты фиксирует повреждение и отправляет сигнал срабатывания на терминал управления выключателем, но для терминала управления эти сообщения отметает как старые. Получаем отказ работы системы защиты! А КЗ будет гореть заданное нами время, достаточное для повреждения оборудования.

Опыт КЗ при спуфинге

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

Ложная работа терминала при спуфинге

Таким образом можно проводить тестирование терминалов РЗА на программно-аппаратных комплексах моделирования в реальном времени РИТМ, в том числе проводить испытания на киберустойчивость. При этом можно оценивать физические процессы в системе и информационный обмен.

Итог

Материал получился объемный, но надеемся, интересным и полезным для специалистов в области электроэнергетики и моделирования.

Если тема моделирования в реальном времени на КПМ РИТМ вам интересна, заходите на наш телеграм-канал. В нем мы регулярно рассказываем о проведенных опытах, выкладываем записи обучающих роликов и анонсируем предстоящие мероприятия.

Ждем вопросы и возможные пожелания в комментариях!

Sv поток 61850 что это

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

Как данные передаются в сети и зачем управлять multicast-потоками?

Unicast

Broadcast

Unknown Unicast

Multicast

Краткий ликбез про MAC-адрес

В чем суть multicast?

Как это работает в реальной ЛВС?

IGMP

PIM

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

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

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

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

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

Зачем необходим multicast?

Нормативная база

Заключение

Рекомендации по реализации различных наборов данных SV-потоков исходя из требований к устройствам РЗА

2. Рекомендации по реализации различных наборов данных SV-потоков исходя из требований к устройствам РЗА

3. Определения

4. Структурная схема ЦПС

5. Подключение ТТ/ТН к шине процесса, 61850

6. Формат кадра (9-2LE) (Wireshark)

7. Формат кадра Sampled values

8. Формат блока APDU (9-2LE)

9. Синхронизация времени

10. Синхронизация времени

11. Синхронизация времени

12. Ethernet 100Mb/s

13. Нагрузка на сеть

14. VLAN

15. Набор передаваемых величин

16. Однолинейные схемы с реализацией на ЦПС

17. Однолинейные схемы с реализацией на ЦПС

18. Однолинейные схемы с реализацией на ЦПС

19. IEC 61869-9:2016

20. Предлагаемые расчетные варианты с 1 или 2 ASDU

21. Выводы

22.

23. Рекомендации по реализации различных наборов данных SV-потоков исходя из требований к устройствам РЗА