СТАНДАРТ МЭК 61850 Информационная модель устройства

 

Как отмечалось в предыдущих публикациях [1, 2], достаточно большая часть стандарта МЭК 61850 посвящена определению требований к описанию информации внутри устройства. Так, седьмая глава [3–6] определяет иерархическую структуру хранения данных внутри устройства и способы обращения к ним.

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

Рассмотрим структуру организации данных.

ЛОГИЧЕСКИЙ УЗЕЛ

Для понимания архитектуры информационной модели, предлагаемой стандартом, полезно начать рассмотрение с логических узлов. Согласно стандарту логический узел (Logical Node) является наименьшим элементом, способным обмениваться данными. Описание класса логического узла и реализуемых им сервисов дано в [4], а описание перечня всех логических узлов, описанных стандартом, – в [6].

Логический узел удобно рассматривать как одну из составных функций устройства. К примеру, рассмотрим класс логического узла PTOC, который предназначен для описания максимальной токовой защиты (ANSI 51) и токовой направленной защиты (ANSI 67). В табл. 1 показан состав данных, входящих в этот логический узел.

Таблица 1. Описание данных класса PTOC

Имя атрибута Тип атрибута* Пояснение О/Н**
LNName nbsp; Наследуется из класса логического узла nbsp;
Данные
Общая информация для логических узлов (наследуются из класса Common Logical Node Class)
Mod INC Режим О
Beh INS Поведение О
Health INS Состояние О
NamPlt LPL Паспортные данные О
OpCntRs INC Сбрасываемый счетчик срабатываний О
Информация о состоянии
Str ACD Пуск О
Op ACT Срабатывание О
TmASt CSD Активная времятоковая характеристика Н
Уставки
TmACrv CURVE Тип времятоковой характеристики Н
StrVal ASG Уставка по току Н
TmMult   Мультипликатор уставки по времени Н
MinOpTmms ING Минимальное время срабатывания Н
MaxOpTmms ING Максимальное время срабатывания Н
OpDlTmms ING Уставка по времени Н
TypRsCrv ING Тип характеристики возврата Н
RsDlTmms ING Уставка времени возврата Н
DirMod ING Направленный режим Н

Примечание
* Классы данных для каждого из атрибутов описаны в главе МЭК 61850-7-3.
** О – обязательный параметр, Н – необязательный параметр.

Например, атрибут Str («Пуск») позволяет фиксировать и передавать другим устройствам данные о факте пуска соответствующей защиты, а атрибут Op («Срабатывание») – о факте срабатывания защиты. Аналогично атрибуты уставок позволяют, обращаясь к устройству по одному из коммуникационных протоколов, считывать текущие данные об уставках и изменять их. Важно отметить, что каждый атрибут задан определенным типом, который в свою очередь предполагает описание структуры данных атрибута. Все типы атрибутов описываются главой 7–3 стандарта. В качестве примера в табл. 2 рассмотрен тип ACD, которому соответствует атрибут Str.

Таблица 2. Класс типа данных ACD

Имя атрибута данных Тип Значение / Диапазон значений
DataName Наследуется из класса GenDataObject или GenSubDataObject (см. МЭК 61850-7-2)
Атрибут данных
Состояние
general BOOLEAN  
dirGeneral ENUMERATED unknown | forward | backward | both
phsA BOOLEAN  
dirPhsA ENUMERATED unknown | forward | backward
phsB BOOLEAN  
dirPhsB ENUMERATED unknown | forward | backward
phsC BOOLEAN  
dirPhsC ENUMERATED unknown | forward | backward
neut BOOLEAN  
dirNeut ENUMERATED unknown | forward | backward
q Quality  
t TimeStamp  
Конфигурация, описания и расширения
d VISIBLE STRING255 Text
dU UNICODE STRING255  
cdcNs VISIBLE STRING255  
cdcName VISIBLE STRING255  
dataNs VISIBLE STRING255  

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

Помимо атрибутов, присущих лишь определенной функции, в логических узлах имеются также общие атрибуты, которые присутствуют во всех логических узлах. К таким атрибутам, в частности, будут относиться «Режим» (Mode), «Поведение» (Beh), «Состояние» (Health), «Паспортные данные» (NamPlt). Эти атрибуты позволяют хранить и управлять сервисными данными по каждой из функций, например, выводить и вводить в работу, отслеживать состояние и т.п.

Каждый класс логического узла имеет стандартизованное обозначение, состоящее из 4 символов. Логические узлы функций защиты начинаются с буквы «Р» (от английского Protection) и имеют остальные три символа, обычно образованные как аббревиатура от названия защиты, например: PTOC – максимальная токовая (в том числе направленная) защита, PIOC – токовая отсечка, PDIS – дистанционная защита, PTUV – защита минимального напряжения и так далее. Всего стандарт предусматривает 19 групп логических узлов [2].

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

В устройстве может быть реализовано несколько экземпляров одного логического узла. Это необходимо при моделировании нескольких ступеней защиты или разных защит, описываемых одним классом. Например, если в устройстве имеется несколько ступеней МТЗ, токовая защита нулевой последовательности, токовая защита обратной последовательности, то каждой из этих функций может быть поставлен в соответствие отдельный логический узел со своим номером экземпляра (Instance). Кроме того, для удобства пользователя логический узел также может иметь префикс, указывающий на его принадлежность к той или иной ступени или функции. В конечном счете имя логического узла состоит из трех частей: префикса, наименования класса логического узла и номера экземпляра (рис. 1). Например, префикс может обозначать, что данный логический узел является отражением токовой защиты обратной последовательности. Номер экземпляра для логических узлов рассматриваемого класса должен отличаться. То есть в устройстве не может быть двух логических узлов одного класса с одинаковым номером экземпляра.

Рис. 1. Составляющие имени логического узла

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

ЛОГИЧЕСКОЕ УСТРОЙСТВО

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

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

Тем не менее существует ряд типичных подходов. В устройствах РЗА ряда производителей логические узлы группируются в логических устройствах по их принадлежности к той или иной группе: «Защита», «Управление», «Измерения», «Регистрация аварийных событий», «Система». Такой подход, в частности, позволяет переводить одно из логических устройств в режим проверки работоспособности (режим TEST), при этом все находящиеся в нем логические узлы переводятся в режим проверки, но не затрагиваются остальные функции устройства.

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

Совокупная модель данных в устройстве может быть представлена в виде древовидной структуры (рис. 2). В таком виде информацию об устройстве можно будет получить при чтении информационной модели устройства по протоколу MMS либо при рассмотрении файла описания устройства в соответствии с МЭК 61850-6.

Рис. 2. Пример информационной модели устройства

НАБОР ДАННЫХ (НД)

НД представляет собой набор ссылок на данные внутри информационной модели устройства. В НД могут быть включены как отдельные атрибуты данных (например, запись PTOC1.Str.general будет соответствовать одному логическому сигналу пуска защиты), так и логические узлы целиком (например PTOC1).

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

Использование наборов данных проиллюстрировано на рис. 3. При рассмотрении контроллера присоединения, на который заведены сигналы о положении всех разъединителей и заземлителей рассматриваемого присоединения, в устройстве должны присутствовать логические узлы, соответствующие каждому из аппаратов (в нашем случае – XSWI1...5). Примером набора данных может служить DATASET с наименованием SwitchPositions, включающий в себя элементы данных Pos каждого из указанных логических узлов. В дальнейшем составленный набор данных может использоваться, например, для сохранения событий в журнале при каждом изменении положения коммутационного аппарата (с использованием сервиса Log), отправки отчета о событии (с использованием сервиса Report) либо быстрого сообщения о событии (с использованием сервиса GOOSE).

Рис. 3. Использование наборов данных

При описании информационной модели устройства в нотации МЭК 61850-6 для размещения описаний наборов данных используется системный логический узел LLN0. Наличие логического узла LLN0 является обязательным для каждого логического устройства. При этом не в каждом логическом устройстве могут размещаться наборы данных, поэтому при проектировании и наладке коммуникаций по МЭК 61850 требуется внимательно проверять размещение наборов данных в логических устройствах. Информацию о том, в каком логическом устройстве должны размещаться наборы данных,обычно предоставляет производитель в сопроводительной документации. Подробнее информация об этом будет рассмотрена в будущих публикациях, затрагивающих язык конфигурирования SCL, описанный шестой главой стандарта.

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

Стандарт МЭК 61850 описывает требования к системам передачи данных, а не к прикладным функциям устройств РЗиА и учета на подстанции. Поэтому стандарт не описывает требования по составу и распределению логических узлов (функций) между устройствами, но зато дает инструменты для организации связей между ними, как бы они ни были распределены.

Рассмотрим пример классической системы, состоящей из измерительного преобразователя, устройства защиты, АУВ, коммутационного аппарата и АРМ. На рис. 4а показано распределение логических узлов в такой системе и коммуникации между ними при выполнении различных функций. От логических узлов измерительных трансформаторов тока и напряжения данные передаются в логический узел дистанционной защиты. Передача данных от узлов TCTR и TVTR узлу PDIS может осуществляться по протоколу МЭК 61850-9-2 (SV). По факту срабатывания дистанционной защиты команда отключения коммутационного аппарата может передаваться на устройство АУВ посредством быстрого сообщения по протоколу МЭК 61850-8-1 (GOOSE). Данные в АУВ поступают на логический узел управления коммутационным аппаратом CSWI, который, будучи реализован в рамках одного устройства вместе с логическим узлом силового выключателя XCBR, будет активировать привод выключателя для выполнения команды отключения.

Данные о срабатывании защиты, отключения выключателя от защиты, а также команды оперативного управления между устройством РЗА и АРМ передаются в виде отчетов либо по механизму «запрос–ответ» по протоколу МЭК 61850-8-1 (MMS). Протоколы, описанные стандартом МЭК 61850, позволяют реализовать все необходимые коммуникации в данной схеме.

На другой схеме функции защиты и АУВ совмещены в одном устройстве, а привод коммутационного аппарата снабжен контроллером с поддержкой МЭК 61850 (рис. 4б). Отличие данной схемы от предыдущей заключается в том, что логический узел CSWI перемещается из устройства управления коммутационным аппаратом в устройство защиты. Узлы PDIS и CSWI расположены в одном устройстве, и данные между ними передаются по внутренней связи. Срабатывание дистанционной защиты будет активировать команду отключения в логическом узле CSWI, который в свою очередь будет передавать эту команду на логический узел силового выключателя XCBR, например, посредством быстрого GOOSE-сообщения.

Рис. 4. Свободное распределение логических узлов
а)



б)


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

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

РАЗРАБОТКА ЭЛЕКТРОННОГО ПРЕДСТАВЛЕНИЯ СТРУКТУРЫ ЭЛЕМЕНТОВ ДАННЫХ

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

Для того чтобы сосредоточить информацию о моделях данных стандарта МЭК 61850 в одном месте, рабочая группа 10 МЭК занимается разработкой UML-модели, которая будет включать в себя описание структуры всех логических узлов, объектов данных и общих классов данных.

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

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

За последние два года была подготовлена сама UML-модель. Поскольку процедура подготовки модели представляла из себя в большей степени механическую работу, требовалось произвести тщательную сверку реализации модели с текстом самого стандарта. В ходе этого процесса был обнаружен целый ряд неточностей в самом стандарте, которые были скорректированы в соответствии с утвержденной процедурой. Почти полностью завершена обработка глав 7-3 и 7-4 стандарта. Продолжается работа над главами 7-410 и 7-420.

Сейчас представляется возможным сформировать главы 7-3 и 7-4 стандарта МЭК 61850 непосредственно на основе имеющейся UML-модели. На первом этапе планируется публикация редакции 2.1 глав 7-3 и 7-4 путем автоматического их формирования из UML-модели. Редакция 2.1 будет основана на редакции 2.0, однако в новой редакции будет произведена корректировка всех ошибок и неточностей, допущенных в предыдущей редакции. Эта работа должна быть завершена до конца 2012 года. После этого UML-модель станет основой для ведения дальнейшей редакторской работы.

ЛИТЕРАТУРА

  1. Аношин А.О., Головин А.В. Протоколы связи в электроэнергетике. Предпосылки для создания стандарта МЭК 61850 // Новости ЭлектроТехники. 2012. № 3(75) .
  2. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Структура документа // Новости ЭлектроТехники. 2012. № 4(76). 
  3. IEC 61850-7-1 (International Standard). Communication Networks and Systems in Substations – Part 7-1: Basic communication structure for substation and feeder equipment – Principles and models.
  4. IEC 61850-7-2 (International Standard). Communication Networks and Systems in Substations – Part 7-2: Basic communication structure for substation and feeder equipment – Abstract communication service interface (ACSI).
  5. IEC 61850-7-3 (International Standard). Communication Networks and Systems in Substations – Part 7-3: Basic communication structure for substation and feeder equipment – Common data classes.
  6. IEC 61850-7-4 (International Standard). Communication Networks and Systems in Substations – Part 7-4: Basic communication structure for substation and feeder equipment – Compatible logical node classes and data classes.
  7. http://news.elteh.ru 
Назад