Коммуникационные протоколы в электроэнергетике: МЭК 61850 — Transcript

Сегодня мы поговорим о протоколе МЭК 61850.

Без сомнения, у всех, кто причастен к электроэнергетике, он на слуху, иногда даже против их воли.

Сейчас это самый нашумевший и самый современный протокол. Одновременно с этим окончательное формирование стандартов протокола не завершено и продолжается до сих пор.

Самая главная идея, которая легла в основу стандарта, — это унификация информационной модели, а значит, взаимодействие между устройствами.

То есть устройства разных фирм должны быть совместимы друг с другом из коробки. В идеале мы должны прийти к чему-то вроде технологии Plug and Play, когда вы подключаете флешку любого производителя к своему компьютеру и не видите разницы в их работе.

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

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

Поэтому сегодня я постараюсь рассказать о работе протокола и с этой стороны тоже. В работе цифровых подстанций можно условно выделить три архитектуры, описанные в корпоративном профиле ФСК 61850.

Первая — это поддержка оборудования только с протоколом MMS. Вторая — MMS и GOOSE. Третья — MMS, GOOSE и SV-потоки мгновенных значений.

Теперь подробнее, что значат эти термины. MMS — это протокол обмена высокого уровня. Он похож на рассмотренный ранее нами 104-й протокол. Он тоже используется для телесигнализации и телеизмерения.

MMS не очень скоростной, зато надёжность доставки обеспечивается на уровне TCP/IP. Самое главное отличие — это наличие унифицированной модели данных, в отличие от карт адресов, задаваемой производителем 104-м протоколом.

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

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

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

Производительности обмена TCP/IP для такой скоростной передачи недостаточно, и требуется построение отдельной шины обмена, называемой шиной процесса.

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

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

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

Ну а теперь мы с вами не добрались до SV-потоков. SV-поток — это передача мгновенных значений по Ethernet. По своей сути такая передача очень похожа на GOOSE-сообщения.

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

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

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

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

Первая попытка сделать универсальную модель данных, в которой адреса будут заменены на функции защиты, была сделана в протоколе МЭК 60870-5-103. Но стандарт получился неудачным и не получил распространения.

Так вот, от этой идеи не отказались, и теперь у нас вместо непонятно к чему привязанных адресов есть логические узлы, которые соответствуют функциям защиты. А если, например, узел максимальной токовой защиты? Конечно. Вот так он выглядит согласно корпоративному профилю ФСК.

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

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

Отдельно хотелось бы сказать про узел LLN0. Этот узел — состояние всего логического устройства. Beh и Mod тут показывают, в каком режиме работает устройство. Работа устройства, например, может быть блокирована.

В стандарте описывается, когда какое состояние выставляется. Объект данных Health показывает состояние устройства, то есть наличие в нём неисправностей. NamePlt является паспортной табличкой устройства. Например, вот как оно выглядит в устройстве Altea БЗП.

Хорошо, с функцией защит мы определились. Но как понять, какие из них отправлять SCADA-системе по протоколу MMS, а какие будут заменять дискретные контакты, например, ЛЗШ, и отправляться при помощи GOOSE?

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

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

Это нужно запомнить, потому что из-за созвучности названий постоянно возникает путаница. То есть CID — это тот же ICD, но в котором пользователь отметил, какие защиты не используются, а какие используются и по каким протоколам следует отправлять различные параметры.

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

Давайте создадим простой ICD-файл и попробуем его открыть в текстовом редакторе. Для создания файла я воспользуюсь демоверсией программы ICD Designer.

Создадим новый файл и дополним его защитой МТЗ. Для этого создадим в нашем логическом устройстве узел 51C. При этом оставим только обязательные атрибуты. Сохраним файл.

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

И далее можно найти созданный узел среди других логических узлов.

Теперь давайте попробуем создать набор данных и отчёт для отправки в АСУ.

Для этого снова переходим в ICD Designer, заходим в узел LLN0, нажимаем создать набор данных. Выберем старт МТЗ и придумаем название для набора данных. Теперь нужно привязать этот набор данных к отчёту MMS.

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

Если мы теперь сравним старый и новый файлы по содержимому, то разница будет в небольшой секции с описанием набора данных и отчёта. Можно заметить, что все те настройки, которые мы задавали ранее, здесь представлены в текстовом виде.

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

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

Открывать файлы можно в бесплатном блокноте, а сравнивать содержимое в Total Commander. Ссылки будут под видео.

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

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

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

Теперь посмотрим, что добавилось по сравнению с прошлым файлом. По аналогии с тем, что мы видели при добавлении отчётов, добавилась секция с объявлением нового набора данных и нового GOOSE-контрол блока.

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

Протокол МЭК 61850 предусматривает передачу полной информационной модели устройства. Поэтому подключение к устройству онлайн эквивалентно открытию файла с настройками.

Тут пользователь может видеть всё, что мы создали до этого: наборы данных, отчёты, GOOSE-контрол блок. И можно посмотреть модель данных. Теперь попробуем подключиться при помощи этой программы к настоящему устройству. Я использую Altea БЗП. Чтобы найти в сети Altea, вводим его IP-адрес. Ищем и подключаемся.

Давайте посмотрим информационную модель устройства. Тут мы видим два узла общего назначения, GGIO. Это универсальные узлы, которые не относятся ни к какой защите, и производитель может использовать их по своему усмотрению. Поскольку абсолютно к любому узлу можно добавить префикс, мы решили добавить свои обозначения. FL означает Flexible Logic, то есть гибкая логика, а In показывает, что данные можно подавать на вход. Внутри нас ждёт 64 выхода гибкой логики и 30 входов.

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

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

Да, в 61850 причины передачи настраиваются со стороны SCADA. Здесь представлено: Data Change — отправка при изменении данных. Это аналог спорадической рассылки, рассмотренной нами ранее в других протоколах. Quality Change — отправка при изменении качества. Например, состояние сигнала не изменилось, но возникла неисправность в устройстве. Data Update — это отправка данных, даже если они не изменились, а произошло их обновление.

Например, мы считали какой-то дискретный вход. Он остаётся неизменным. Так вот, при выборе этого параметра устройство всё равно будет в таком случае отправлять нам состояние этого входа, даже без опроса от SCADA.

Integrity — это аналог общего опроса. Тут же ниже можно указать его цикл в миллисекундах. General Interrogation — это тоже общий опрос, но только уже не периодический, а единоразовый, выполняемый по инициативе SCADA. Оставим всё без изменений и подключимся.

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

Кстати, если у вас Wireshark некорректно распознаёт пакеты MMS как протокол Press, в описании будет ссылка, как это исправить.

Теперь отправим команду телеуправления. Для этого найдём нужный сигнал в модели данных и нажмём Write. Видим, что состояние выхода гибкой логики изменилось. Теперь найдём это сообщение в анализаторе. А причина передачи — изменение данных. При этом были отправлены только те данные, которые на самом деле изменились, в отличие от общего опроса, в котором присылается вся модель. Здесь же можно посмотреть файлы осциллограмм, находящиеся в устройстве. Для этого просто перейдём во вкладку с файлами и нажмём открыть. Скорость тут заметно лучше, чем по другим интерфейсам. Никаких действий больше не требуется. Файлы передаются в оригинальном виде.

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

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

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