Протокол MMS

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

• MMS (Manufacturing Message Specification)— протокол передачи данных по технологии «клиент-сервер».
• SV (МЭК 61850-9-2) — протокол передачи мгновенных значений тока и напряжения от измерительных трансформаторов

В данной публикации мы рассмотрим протокол MMS и вопросы его применения в системах РЗА.

Строго говоря, стандарт МЭК 61850 не описывает протокол MMS. Глава МЭК 61850-8-1 описывает лишь порядок назначения сервисов передачи данных, описанных стандартом МЭК 61850, на протокол MMS, описанный стандартом ИСО/МЭК 9506. Для того, чтобы лучше понять что это означает необходимо подробнее рассмотреть каким образом стандарт МЭК 61850 описывает абстрактные коммуникационные сервисы, и для чего это сделано.

Абстрактные сервисы передачи данных

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

Абстрактный коммуникационный интерфейс, описываемый МЭК 61850-7-2, включает в себя как описание моделей устройств (то есть стандартизует понятия «логического устройства», «логического узла», «управляющего блока» и т.п.), так и описание сервисов передачи данных. Один из таких сервисов — SendGOOSEMessage, — его назначение на протокол Ethernet мы рассмотрели в предыдущей публикации. Помимо указанного сервиса, главой 7-2 описывается ещё более 60 сервисов, стандартизующих процедуру установления связи между клиентом и сервером (Associate, Abort, Release), считывания информационной модели (GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory), считывание значений переменных (GetAllDataValues, GetDataValues и т.д.), передачу значений переменных в виде отчётов (Report) и другие. Передача данных в перечисленных сервисах осуществляется по технологии «клиент-сервер». Например, сервером в данном случае может выступать устройство релейной защиты, а клиентом — SCADA-система. Сервисы считывания информационной модели позволяют клиенту считать с устройства полную информационную модель, то есть воссоздать дерево из логических устройств, логических узлов, элементов и атрибутов данных. При этом клиент получит полное семантическое описание данных и их структуру. Сервисы считывания значений переменных позволяют считать фактические значения атрибутов данных, например, методом периодического опроса. Сервис передачи отчётов позволяет настроить отправку определенных данных при выполнении определенных условий. Одним из вариантов такого условия может быть изменение того или иного рода, связанное с одним или несколькими элементами из набора данных. Для реализации описанных абстрактных моделей передачи данных в стандарте МЭК 61850 описано назначение абстрактных моделей на конкретный протокол. Для рассматриваемых сервисов таким протоколом является MMS, описанный стандартом ИСО/МЭК 9506.

История MMS

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

Задачи, решавшиеся при разработке протокола MMS были в целом схожи с задачами, которые решаются стандартом МЭК 61850:

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

Задачи MMS

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

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

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

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

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

Выполнение прикладных задач сбора данных

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

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

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

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

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

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

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

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

Cписок литературы

1. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Протокол GOOSE // Новости ЭлектроТехники. 2012. № 6 (78).

2. MMS. Presentation by Prof. Dr. H. Kirrmann, ABB Research Center, Baden, Switzerland.

3. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Информационная модель устройства // Новости ЭлектроТехники. 2012. №5 (77).