Релейная защита • МЭК 61850

Продолжаем цикл публикаций «Релейная защита. МЭК 61850», в рамках которого будут рассмотрены все части стандарта и описываемых им протоколов (начало цикла – см. «Новости ЭлектроТехники» № 3(75) 2012, № 4(76) 2012, № 5(77) 2012, № 6(78) 2012).
Члены рабочей группы 10 Технического комитета 57 «Управление электроэнергетическими системами и сопутствующие технологии обмена информацией» МЭК, занимающейся разработкой стандарта, Алексей Олегович Аношин и Александр Валерьевич Головин рассматривают сегодня протокол передачи данных по технологии сервер–клиент – MMS.

Алексей Аношин, исполнительный директор	Александр Головин, технический директор
ООО «ТЕКВЕЛ», г. Москва

СТАНДАРТ МЭК 61850
Протокол MMS

В публикации [1] мы рассмотрели один из важных и наиболее обсуждаемых коммуникационных протоколов, описанных стандартом МЭК 61850, – протокол GOOSE, предназначенный для передачи в первую очередь дискретных сигналов между устройствами релейной защиты и автоматики (РЗА) в цифровом виде. Помимо GOOSE, стандартом описаны:

• MMS (Manufacturing Message Specification) – протокол передачи данных по технологии клиент–сервер;
• SV (МЭК 61850-9-2) – протокол передачи мгновенных значений тока и напряжения от измерительных трансформаторов.
  Строго говоря, стандарт МЭК 61850 не описывает протокол MMS. В главе МЭК 61850-8-1 указывается лишь порядок назначения сервисов передачи данных.

АБСТРАКТНЫЕ СЕРВИСЫ ПЕРЕДАЧИ ДАННЫХ

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

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

Абстрактный коммуникационный интерфейс в МЭК 61850-7-2 включает в себя как модели устройств (то есть стандартизует понятия «логическое устройство», «логический узел», «управляющий блок» и т.п.), так и описание сервисов передачи данных.

Помимо сервиса GOOSE, главой 7-2 описывается еще более 60 сервисов, стандартизующих:

• процедуру установления связи между клиентом и сервером (Associate, Abort, Release);
• процедуру считывания информационной модели (Get­ServerDirectory, GetLogicalDeviceDirectory, GetLogi­cal­NodeDirectory);
• процедуру считывания значений переменных (GetAll­DataValues, GetDataValues и т.д.);
• передачу значений переменных в виде отчетов (Report) и другие.

Передача данных в перечисленных сервисах осуществляется по технологии клиент–сервер. Например, сервером в данном случае может выступать устройство РЗА, а клиентом – SCADA-система.

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

Для реализации описанных абстрактных моделей передачи данных в стандарте МЭК 61850 дано назначение абстрактных моделей на конкретный протокол. Для рассматриваемых сервисов таким протоколом является MMS, описанный стандартом ИСО/МЭК 9506.

ИСТОРИЯ MMS

В 1980 году протокол MMS (Manufacturing Message Specification) был разработан для автоматизации автомобильного производства компанией General Motors. Однако широкое распространение протокол получил лишь после того, как был существенно переработан компанией Boeing и стал активно использоваться в автомобильной и аэрокосмической отраслях производителями программируемых логических контроллеров (Siemens, Schneider Electric, Daimler, ABB) [2].

В 1990 году MMS был стандартизован как ИСО/МЭК 9506. На сегодняшний день существует вторая редакция этого стандарта, вышедшая в 2003 году. Задачи, решавшиеся при разработке протокола MMS, были в целом схожи с задачами, которые решаются стандартом МЭК 61850:

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

ЗАДАЧИ MMS

MMS определяет:

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

Таким образом, MMS не определяет прикладных сервисов, которые определены стандартом МЭК 61850. Кроме того, протокол MMS сам по себе не является коммуникационным протоколом, он лишь определяет сообщения, которые должны передаваться по определенной сети. В качестве коммуникационного протокола в MMS используется стек TCP/IP. Общая структура применения протокола MMS для реализации сервисов передачи данных в соответствии с МЭК 61850 представлена на рис. 1.

Рис. 1. Диаграмма передачи данных по протоколу MMS

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

ВЫПОЛНЕНИЕ ПРИКЛАДНЫХ ЗАДАЧ СБОРА ДАННЫХ

Основное назначение протокола MMS – реализация функций АСУ ТП, то есть сбор данных телесигнализации и телеизмерений, а также передача команд телеуправления.

Для целей сбора информации протокол MMS предоставляет две основные возможности:

• сбор данных с использованием периодического опроса сервера(-ов) клиентом;
• передача данных клиенту сервером в виде отчетов (спорадически).

Оба этих способа востребованы при наладке и эксплуатации системы АСУ ТП. Для определения областей их применения подробнее рассмотрим механизмы работы каждого (рис. 2).

Рис. 2. Механизм передачи данных клиент–сервер

Сбор данных путем периодического опроса сервера клиентом

На первом этапе между устройствами «клиент» и «сервер» устанавливается соединение (сервис Association). Установку соединения инициирует клиент, обращаясь к серверу по его IP-адресу.

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

• после запроса GetServerDirectory сервер вернет перечень доступных логических устройств;
• после отдельного запроса GetLogicalDeviceDirectory для каждого логического устройства сервер вернет перечень логических узлов в каждом из логических устройств;
• запрос GetLogicalNodeDirectory для каждого отдельного логического узла возвратит его объекты и атрибуты данных.

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

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

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

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

Передача данных клиенту сервером в виде отчетов

МЭК 61850 определяет два вида отчетов – буферизируемые и небуферизируемые.

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

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

Второе, что требуется отметить, это то, что когда речь идет об отчетах, подразумевается контроль не всех объектов и атрибутов данных информационной модели сервера, а лишь тех, которые нас интересуют, объединенных в так называемые «наборы данных» [3].

Третий важный момент: можно настроить сервер не только на передачу всего контролируемого набора данных, но и на передачу только тех объектов/атрибутов данных, с которыми происходят определенного рода события за предопределенный пользователем временной интервал.

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

• изменение данных (dchg). При задании этого параметра в отчет будут включаться только те атрибуты данных, значения которых изменились, или только те объекты данных, значения атрибутов которых изменились;
• изменение атрибута качества (qchg). При задании этого параметра в отчет будут включаться только те атрибуты качества, значения которых изменились, или только те объекты данных, атрибуты качества которых изменились;
• обновление данных (dupd). При задании этого параметра в отчет будут включаться только те атрибуты или объекты данных, значения которых были обновлены. Под обновлением понимается, к примеру, периодическое вычисление той или иной гармонической составляющей и запись в соответствующий атрибут данных ее нового значения. Однако даже в том случае, если значение по результатам вычислений в новом периоде не изменилось, объект данных или соответствующий атрибут данных включаются в отчет.

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

СРАВНИТЕЛЬНЫЙ АНАЛИЗ СБОРА ДАННЫХ ПУТЕМ ПЕРИОДИЧЕСКИХ ОПРОСОВ И В ВИДЕ ОТЧЕТОВ

Механизм передачи отчетов обладает важными преимуществами перед методом периодического опроса (polling):

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

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

ДРУГИЕ СЕРВИСЫ

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

ВЫВОДЫ

Протокол MMS является одним из протоколов, на который могут быть назначены абстрактные сервисы, описанные стандартом МЭК 61850-7-2. При этом появление новых протоколов не будет оказывать влияние на модели, описанные стандартом, обеспечивая неизменность стандарта со временем.

Для назначения моделей и сервисов на протокол MMS используется глава МЭК 61850-8-1.

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

ЛИТЕРАТУРА

1. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Протокол GOOSE // Новости ЭлектроТехники. 2012. № 6(78).
2. MMS. Presentation by Prof. Dr. H. Kirrmann, ABB Research Center, Baden, Switzerland.
3. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Информационная модель устройства // Новости ЭлектроТехники. 2012. № 5(77).