Как отмечалось в публикациях [1, 2], достаточно большая часть стандарта МЭК 61850 посвящена определению требований к описанию информации внутри устройства. Так, седьмая глава стандарта МЭК 61850 [3, 4] определяет иерархическую структуру хранения данных внутри устройства и способы обращения к ним.
Стандартизация структуры хранения и наименования данных крайне важна, поскольку именно это позволяет достигать совместимости при обмене данными между устройствами различных фирм-производителей, а также при параметрировании передачи данных между устройствами при помощи программного обеспечения независимых разработчиков.
Рассмотрим структуру организации данных внутри устройства в соответствии с МЭК 61850.
Для понимания архитектуры информационной модели, предлагаемой стандартом полезно начать рассмотрение с «логических узлов». Согласно стандарту Логический узел (Logical Node) является наименьшим элементом, способным обмениваться данными. Описание класса логического узла и реализуемых им сервисов дано в главе МЭК 61850-7-2 [4], а описание перечня всех логических узлов, описанных стандартом, приведено в главе 7-4 [6]. Рассмотрим что же такое логический узел и какие они бывают.
Логический узел удобно рассматривать как одну из составных функций устройства. К примеру, рассмотрим класс логического узла PTOC. Данный класс предназначен для описания максимальной токовой защиты (ANSI 51) и токовой направленной защиты (ANSI 67). Рассмотрим состав данных, входящих в данный логический узел (см. Таблицу 1).
Таблица 1. Описание данных класса PTOC.
| Имя атрибута | Тип атрибута* | Пояснение | О/Н** |
| LNName | Наследуется из класса логического узла | ||
| Данные | |||
| Общая информация для логических узлов (наследуются из класса 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 [5] стандарта.
Например, можем рассмотреть тип ACD, которому соответствует атрибут Str. (см. Таблицу 2).
Таблица 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 групп логических узлов (см. таблицу 3).
Таблица 3. Перечень групп логических узлов.
| Указатель группы | Наименование группы |
| A | Автоматическое управление |
| B | Зарезервировано |
| C | Диспетчерское управление |
| D | Распределенные источники энергии |
| E | Зарезервировано |
| F | Функциональные блоки |
| G | Общие функции |
| H | Гидроэнергетика |
| I | Интерфейсы и архивирование |
| J | Зарезервировано |
| K | Механическое и неэлектрическое оборудование |
| L | Системные логические узлы |
| M | Учёт и измерения |
| N | Зарезервировано |
| O | Зарезервировано |
| P | Функции защиты |
| Q | Контроль качества электрической энергии |
| R | Функции защиты |
| S* | Диспетчерское управление и мониторинг |
| T* | Измерительные трансформаторы и датчики |
| U | Зарезервировано |
| V | Зарезервировано |
| W | Ветроэнергетика |
| X* | Коммутационные аппараты |
| Y* | Силовые трансформаторы и связанные функции |
| Z* | Иное электротехническое оборудование |
| * Логические узлы этих групп существуют в выделенных ИЭУ при условии что используется шина процесса. Если шина процесса не используются, то указанные логические узлы соответствуют модулям ввода/вывода и расположены в ИЭУ, подключенном медными связями к оборудованию и расположенном уровнем выше (например, на уровне присоединения) и представляют внешнее устройство по его входам и выходам (проекция процесса). | |
Отдельно следует упомянуть о так называемых «общих логических» узлах, класс которых имеет наименование GGIO. Общие логические узлы предназначены для моделирования узлов данных, не подпадающих под описание ни одной из остальных функциональных групп (например, сигналы пользовательской логики). В общем случае логическими узлами GGIO могут быть описаны и стандартизованные функции (стандартом это не запрещено), однако при этом теряется семантика, то есть проектировщик или наладчик не сможет быстро определить что за функция «скрыта» за логическим узлом GGIO. С точки зрения сохранения семантики логические узлы GGIO полезно использовать только для моделирования функций свободно-программируемой логики, не описываемых стандартными логическими узлами.
В устройстве может быть реализовано несколько экземпляров одного логического узла. Это необходимо, например, при моделировании нескольких ступеней защиты или разных защит, описываемых одним классом.
Например, если в устройстве имеется несколько ступеней МТЗ, токовая защита нулевой последовательности, токовая защита обратной последовательности, то каждой из этих функций может быть поставлен в соответствие отдельный логический узел со своим номером экземпляра (Instance). Кроме того, для удобства пользователя логический узел также может иметь префикс, указывающий на его принадлежность к той или иной ступени или функции. В конечном счёте имя логического узла состоит из трёх частей: префикса, наименования класса логического узла и номера экземпляра (рис. 1). Например, префикс может обозначать, что данный логический узел является отражением токовой защиты обратной последовательности. Номер экземпляра для логических узлов рассматриваемого класса должен отличаться. То есть в устройстве не может быть двух логических узлов одного класса с одинаковым номером экземпляра.
Рис. 1. Имя логического узла.Отметим один важный момент. Логический узел является лишь виртуальным отображением функции, и позволяет вводить в неё определенные данные и выводить их. При этом сама функция представляется лишь «чёрным ящиком», имеющим входы и выходы в соответствии с описанием логического узла. То есть стандарт МЭК 61850 не описывает никаких прикладных требований к функциям, таких как быстродействие, чувствительность, рекомендуемые к использованию характеристики и т.п.
Стандартом положено, что внутри физического устройства реализуется сервер МЭК 61850, который отвечает за организацию внешних коммуникаций устройства с другими устройствами.
В сервере может быть реализовано одно или несколько так называемых «логических устройств». Основным назначением логических устройств является группировка логических узлов. Стандартом не регламентировано сколько логических устройств должно быть внутри физического устройства и как должны распределяться логические узлы по устройствам. Решения по данному вопросу принимаются производителем и, вообще говоря, не влияют на возможность стыковки устройства с другими. Тем не менее, существует ряд типичных подходов производителей устройств к работе с логическими устройствами. В устройствах РЗА ряда производителей логические узлы группируются в логических устройствах по их принадлежности к той или иной группе: Защита, Управление, Измерения, Регистрация аварийных событий, Система. Такой подход, в частности, позволяет переводить одно из логических устройств в режим проверки работоспособности (режим «TEST»), при этом переводя и все, находящиеся в нём логические узлы в режим проверки, но не затрагивая остальную функциональность устройства.
Наличие в одном сервере нескольких логических устройств будет требовать аккуратности и квалификации при работе с устройством, поскольку зачастую функциональность каждого из логических устройств ограничена, так, в ряде логических устройств могут быть созданы управляющие блоки, а в других нет. Обычно соответствующая информация предоставляется производителем в сопроводительной документации к устройству и должна приниматься во внимании при конфигурировании.
Совокупная модель данных в устройстве может быть представлена в виде древовидной структуры (см. рис. 2). В таком виде информацию об устройстве можно будет получить при чтении информационной модели устройства по протоколу MMS, либо при рассмотрении файла описания устройства в соответствии с МЭК 61850-6.
Рис. 2. Модель данных устройства.Наборы данных
Элементы данных в сервере МЭК 61850 представляются в виде дерева и, при условии поддержки протокола MMS, значения данных для каждого из элементов могут быть считаны в таком виде. Однако для формирования GOOSE-сообщений, а также для сохранения данных в журналы и передачи данных в виде отчётов требуется выбрать, какие именно данные необходимо отслеживать. С этой целью формируются наборы данных (DATASET).
Набор данных представляет собой набор ссылок на данные внутри информационной модели устройства. В набор данных могут быть включены как отдельные атрибуты данных (например, запись PTOC1.Str.general будет соответствовать одному логическому сигналу пуска защиты), так и логические узлы целиком (например, PTOC1, что будет соответствовать включению всех элементов и атрибутов данных).
В зависимости от реализации устройства могут поддерживать различное количество наборов данных. Кроме того, устройства могут иметь фиксированные (то есть когда набор данных нельзя изменить), либо конфигурируемые наборы данных. Также возможны различные степени свободы конфигурации наборов данных: изменение данных, изменение наименования и т.п.
Использование наборов данных проиллюстрировано на рис. 3. При рассмотрении контроллера присоединения, на который заведены сигналы о положении всех разъединителей и заземлителей рассматриваемого присоединения, в устройстве должны присутствовать логические узлы, соответствующие каждому из аппаратов (в нашем случае — XSWI15). В таком случае примером набора данных может служить 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
С расширением области применения стандарта МЭК 61850, за последние годы значительно увеличилось число классов логических устройств и классов данных [2]. При этом описания структуры классов логических узлов и классов данных присутствуют в различных главах стандарта МЭК 61850, разработка которых ведется различными рабочими группами.
Для того, чтобы сосредоточить информацию о моделях данных стандарта МЭК 61850 в одном месте рабочая группа 10 Международной Электротехнической Комиссии (МЭК) занимается разработкой UML-модели, которая будет включать в себя описание структуры всех логических узлов, объектов данных и общих классов данных.
Конечной целью данной работы является разработка стандарта в виде электронной базы данных, включающей в себя описание моделей элементов, такая электронная база данных может быть непосредственно использована при разработке программного обеспечения и интеллектуальных электронных устройств (ИЭУ). Это означает, что вместо того, чтобы просматривать сотни страниц стандарта в поисках необходимо элемента (логического узла, объекта данных или класса данных), пользователь сможет оперативно найти и просмотреть структуру соответствующей модели в веб-браузере. Использование электронных версий моделей позволит повысить качество разрабатываемых устройств. Кроме того, в рамках этой электронной базы данных становится возможным и планируется реализовать функциональность идентификации ошибок, допущенных при разработке стандарта, их утверждения и корректировки.
За последние два года была подготовлена сама UML-модель. Поскольку процедура подготовки модели представляла из себя в большей степени механическую работу, требовалось произвести тщательную сверку реализации модели с текстом самого стандарта. В ходе этого процесса был обнаружен целый ряд неточностей в самом стандарте, которые были скорректированы в соответствии с утвержденной процедурой. Почти полностью завершена обработка глав 7-3 и 7-4 стандарта. Продолжается работа над главами 7-410 и 7-420.
Сейчас представляется возможным сформировать главы 7-3 и 7-4 стандарта МЭК 61850 непосредственно на основе имеющейся UML-модели. На первом этапе планируется публикация редакции 2.1 глав 7-4 и 7-3 путем автоматического их формирования из UML-модели. Редакция 2.1 будет основана на редакции 2.0, однако в новой редакции будет произведена корректировка всех утвержденных ошибок и неточностей предыдущей редакции. Эта работа должна быть завершена до конца 2012 года. Начиная с этого момента времени, UML-модель станет основой для ведения дальнейшей редакторской работы.
Cписок литературы
- «Протоколы связи в электроэнергетике. Предпосылки для создания стандарта МЭК 61850». Новости ЭлектроТехники №3 (75), 2012.
- «Стандарт МЭК 61850. Структура документа». Новости ЭлектроТехники №4 (76), 2012.
- 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.
- 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).
- 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.
- 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.
Рейтинг
статьи