**Коммуникационные протоколы в электроэнергетике: МЭК 61850 — Transcript & SRT | SozAI**
Source: https://sozai.app/transcript/kommunikatsionnye-protokoly-v-elektroenergetike-mek-61850-transcript/

Answers

## Questions about this video

Какова основная идея, лежащая в основе стандарта МЭК 61850?

Основная идея стандарта МЭК 61850 заключается в унификации информационной модели, что обеспечивает совместимость устройств разных производителей. Это позволяет устройствам взаимодействовать друг с другом «из коробки», подобно технологии Plug and Play.

Какие три архитектуры цифровых подстанций описаны в корпоративном профиле ФСК 61850?

В корпоративном профиле ФСК 61850 описаны три архитектуры: первая поддерживает только протокол MMS, вторая включает MMS и GOOSE, а третья использует MMS, GOOSE и SV-потоки мгновенных значений.

В чем главное отличие протокола MMS от 104-го протокола?

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

## Full Transcript — Download SRT & Markdown

00:03

Speaker A

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

00:08

Speaker A

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

00:14

Speaker A

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

00:24

Speaker A

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

00:33

Speaker A

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

00:46

Speaker A

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

00:56

Speaker A

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

01:53

Speaker A

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

02:06

Speaker A

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

02:17

Speaker A

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

02:29

Speaker A

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

03:23

Speaker A

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

03:41

Speaker A

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

03:52

Speaker A

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

04:02

Speaker A

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

04:11

Speaker A

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

05:02

Speaker A

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

05:18

Speaker A

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

05:26

Speaker A

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

05:35

Speaker A

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

05:57

Speaker A

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

06:54

Speaker A

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

07:07

Speaker A

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

07:27

Speaker A

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

08:20

Speaker A

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

08:36

Speaker A

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

08:55

Speaker A

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

09:04

Speaker A

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

10:00

Speaker A

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

10:13

Speaker A

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

10:26

Speaker A

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

10:45

Speaker A

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

11:54

Speaker A

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

12:09

Speaker A

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

12:16

Speaker A

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

12:26

Speaker A

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

13:29

Speaker A

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

13:55

Speaker A

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

14:00

Speaker A

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

14:04

Speaker A

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

15:01

Speaker A

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

15:39

Speaker A

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

15:54

Speaker A

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

16:42

Speaker A

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

16:59

Speaker A

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

17:07

Speaker A

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

17:14

Speaker A

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

17:34

Speaker A

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

18:29

Speaker A

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

18:42

Speaker A

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

18:51

Speaker A

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

19:04

Speaker A

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

20:07

Speaker A

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

20:40

Speaker A

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

20:56

Speaker A

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

21:51

Speaker A

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

22:20

Speaker A

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

22:32

Speaker A

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

23:28

Speaker A

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

23:46

Speaker A

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

23:54

Speaker A

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

25:16

Speaker A

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

25:32

Speaker A

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

25:44

Speaker A

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

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/ai-flashcard-generator/?from=transcript&id=7285)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=7285)
- [Краткое содержание этого видео](https://sozai.app/ru/youtube-video-summarizer/?from=transcript&id=7285)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/kommunikatsionnye-protokoly-v-elektroenergetike-mek-61850-transcript/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/