sv поток 61850 что это
Реализация захвата и обработки потоков Sampled Values МЭК 61850‑9‑2 (LE) в ПТК EKRASCADA
В настоящее время в сфере электроэнергетики все чаще можно наблюдать тенденции, направленные на создание цифровых подстанций.
• формат файлов конфигурации интеллектуальных электронных устройств (ИЭУ);
• модели данных ИЭУ, которые определяют набор поддерживаемых ими функций;
• протоколы информационного обмена: как для взаимодействия ИЭУ друг с другом, так и для взаимодействия с другими устройствами подстанции (Manufacturing Message Specification (MMS), Generic Object Oriented Substation Event (GOOSE), Sampled Values (SV)).
Глава МЭК 61850‑9‑2 стандарта определяет передачу мгновенных значений измерений по сети Ethernet (ISO / IEC 8802‑3). Данные передаются по «шине процесса». В соответствии с частью МЭК 61850‑1 под «шиной процесса» понимается коммуникационная сеть, к которой подключены ИЭУ полевого уровня (коммутационные аппараты, измерительные преобразователи, измерительные трансформаторы). Передача данных по «шине процесса» осуществляется с использованием протоколов, определенных в стандарте. Мгновенные значения токов и напряжений оцифровываются в устройствах и передаются в составе сообщений SV.
Для захвата потоков SV с помощью системы EKRASCADA необходимо создать соответствующий проект. Задачу создания проекта решает средство конфигурирования EKRASCADA STUDIO. В проект необходимо добавить устройства, потоки SV с которых нужно захватить. Для этих целей используется компонент подсистемы сбора данных «Клиент МЭК-61850», который поддерживает протоколы MMS, GOOSE, SV. Устройства добавляются в виде файлов в формате SCL (SCD, ICD, CID), а также с помощью функции «online browsing». В процессе конфигурирования имеется возможность изменять следующие параметры блоков управления SV сообщениями:
• идентификатор SMV (smvID) – используется для определения принадлежности пакета SV определенному блоку управления, определенного ИЭУ;
• идентификатор приложения (APPID) – используется для фильтрации сообщений SV на канальном уровне, а также для определения принадлежности определенному блоку управления, определенного ИЭУ;
• MAC-адрес подсети – используется для фильтрации сообщений SV на канальном уровне.
Дополнительно можно скорректировать список переменных, добавляемых в систему. В качестве потребителя данных будет использоваться подсистема осциллографирования, которая поддерживает запись сконфигурированных переменных в осциллограмму в формате COMTRADE. В этом и будет заключаться обработка сигналов. После завершения конфигурирования необходимо применить созданный проект. С этого момента система EKRASCADA начинает выполнять захват потоков SV и обработку значений сигналов.
На рисунке представлена схема взаимодействия при выполнении захвата и обработки потоков Sampled Values. В схеме участвуют:
• два испытательных комплекса Omicron CMC 356 – каждое устройство обеспечивает генерацию трех потоков SV, т. е. содержит три блока управления сообщениями Sampled Values. Каждый поток содержит 8 сигналов: 4 тока, 4 напряжения;
• сервер единого времени ЭКРА «СВ-03» – обеспечивает синхронизацию времени для:
• устройств Omicron CMC 356 по протоколу PTP v2 с точностью до 1 микросекунды;
• ПК с системой EKRASCADA по протоколу SNTP с точностью до 10 миллисекунд;
• индустриальный коммутатор Ethernet 100 Мбит / с – обеспечивает обмен данными;
• индустриальный ПК с системой EKRASCADA – обеспечивает захват потоков SV и обработку значений сигналов.
Рассмотрим алгоритм получения пакетов SV. Можно выделить следующие основные шаги:
1. Получить пакет;
2. Проверить наличие MAC-адреса подсети (MAC-адрес приемника) в списке известных MAC-адресов подсети;
3. Проверить тип инкапсулированного в Ethernet кадра протокола: 802.1Q VLAN (0x8100), IEC 61850 SV (0x88ba);
4. При наличии 802.1Q VLAN проверить тип инкапсулированного в пакет протокола: IEC 61850 SV (0x88ba);
5. Проверить наличие значения поля «APPID» в списке известных идентификаторов приложений;
6. Выполнить разбор ASN.1 части пакета (sampled values pdu);
7. Выбрать ASDU;
8. Проверить наличие информации о полученном сообщении SV: это осуществляется путем поиска по хеш-таблице. В качестве ключа используется комбинированный хеш значений «APPID» и «svID»;
9. При наличии поля «datSet» проверить корректность ссылки на набор данных соответствующего блока управления SV сообщениями.
10. Выполнить разбор секции «Sample» («seqData») в соответствии с информацией о типах в текущем наборе данных;
11. полученные данные передать в блок управления SV сообщениями;
12. Повторить пункты 7‑11 для каждого ASDU;
13. Проверить корректность значения поля «ConfRev»;
14. Добавить сообщение в циклическую сортируемую по значению поля «smpCnt» очередь обработки;
15. Выполнить обработку сообщения с учетом обработанных ранее сообщений (дедупликация).
Далее данные передаются в систему EKRASCADA. Потребителем данных является подсистема осциллографирования, которая выполняет запись осциллограммы с ранее сконфигурированными переменными, при переходе пускового сигнала в активное состояние.
Для проверки корректности реализации захвата и обработки SV потоков использовалось ПО для сетевого анализа пакетов Wireshark версии 2.0.1. Данное ПО поддерживает декодирование пакетов SV, а также декодирование секции «seqData» в соответствии с МЭК 61850‑9‑2 (LE). Для визуального анализа корректности записанных осциллограмм применялось ПО Omicron SVScout версии 1.10.197. SVScout декодирует поток данных SV и отображает значения сигналов в виде графика. В полной версии поддерживается запись осциллограмм.
В заключение отметим, что в результате реализации функционала захвата и обработки потоков Sampled Values МЭК 61850‑9‑2 (LE) в ПТК EKRASCADA появилась возможность использовать систему в качестве регистратора аварийных событий.
Литература
IEC 61850. Part 1: Introduction and overview.
IEC 61850. Part 6: Configuration description language for communication in electrical sub-stations related to IEDs.
IEC 61850. Part 7‑2: Basic information and communication structure – Abstract communication service interface (ACSI).
IEC 61850. Part 7‑3: Basic communication structure – Common data classes.
IEC 61850. Part 7‑4: Basic communication structure – Compatible logical node classes and data object classes.
IEC 61850. Part 9‑2: Specific communication service mapping (SCSM) – Sampled values over ISO / IEC 8802‑3.
IEC 61850‑9‑2 LE: Implementation Guideline for Digital Interface to Instrument Transformers Using IEC 61850‑9‑2.
ISO / IEC 8825‑1:2000, Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
Как управлять потоками в ЛВС Цифровой Подстанции?
Цифровая Подстанция – это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде 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 регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.