Базовые прикладные профили в МЭК 61850. Кто их напишет и нужны ли они вообще?

Первая редакция технического отчета IEC TR 61850-7-6 «Communication networks and systems for power utility automation – Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850» была опубликована 16.01.2019, хотя голосование по нему в МЭК завершилось в августе 2018 года, а работа над ним велась ещё с 2014 года О_о.

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

Технический отчёт IEC TR 61850-7-6:2019 — это руководящие указания по созданию прикладных / функциональных профилей в рамках создания базовых прикладных профилей (БПП). Такие базовые прикладные профили представляют собой фундамент для построения совместимых систем при реализации типовых функций в рамках подстанции или при взаимодействии функций между подстанциями. БПП предназначены для того, чтобы определить необходимый набор обязательных атрибутов функций из общего множества возможностей, предоставляемых стандартом, для обеспечения совместимости решений на отдельных рынках.

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

Что такое BAP и зачем он нужен?

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

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

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

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

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

• Измерения от измерительного трансформатора тока (TCTR.AmpSv) поступают в логические узлы токовой отсечки (PIOC) и максимальной токовой защиты (PTOC).

• Сигналы срабатывания МТЗ и ТО (PTOC.Op и PIOC.Op, соответственно) передаются на логический узел силового выключателя (XCBR), инициируя его отключение.

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

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

Во-первых, описание структурно-функциональных схем в профиле позволяет однозначно определить обязательно требуемые объекты данных (или доопределить новые, если они не предусмотрены стандартом). Например, в случае выше мы видим, что из всех объектов данных логического узла PTRC в нашем случае необходимым является только PTRC.Tr, реализация остальных в рассмотренном случае не требуется.

Во-вторых, по такой схеме мы можем определить объем входных сигналов, которые требуется заводить внутрь логических узлов (например, узла XCBR). Причём можем видеть, что рассмотренные варианты с логическим узлом PTRC и без него отличаются в этом смысле: при наличии PTRC мы требуем от ввода в XCBR только одного сигнала (PTRC.Tr), тогда как без узла PTRC нам требуется ввод двух сигналов (PTOC.Op, PIOC.Op), а также, очевидно, дополнительная логика «или» внутри самого XCBR.

Почему нельзя было все требования сразу определить стандартом?

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

Кто уже делает профили стандарта IEC 61850 и сколько их будет?

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

• E3 (консорциум энергетических компаний Испании, в который входит RED ELÉCTRICA DE ESPAÑA, IBERDROLA, ENDESA DISTRIBUCIÓN, GAS NATURAL FENOSA, HIDRO CANTÁBRICO). Консорциум начал работу в 2008 году и в 2010 году выпустил совместный отчет, содержащий спецификацию по применению стандарта МЭК 61850. Строго говоря, этот документ не является прикладным профилем стандарта МЭК 61850 в понимании сегодняшнего МЭК 61850-7-6 и даёт более широкий охват, определяя также топологии сетей, требования к синхронизации времени и тп.

• ГСК Китая. К сожалению, у авторов отсутствуют достоверные и подтвержденные данные по текущему статусу профилей в Китае, а также их актуальной версии. Известно, что существует стандарт ГСКК Q/GDW 396 - 2012, определяющий требования к информационной модели IEC 61850 в устройствах. Стандарт, равно как и E3, не соответствует руководящим указаниям по составлению BAP (что не удивительно — он издан на 6 лет раньше). Основной упор в стандарте сделан на следующие аспекты: наименования логических устройств в физических устройствах, состав и наименования логических узлов в соответствующих логических устройствах, состав блоков управления и их наименования, расширение состава объектов данных логических узлов и описание новых классов логических узлов.

• ENTSO-E (Европейская сеть операторов магистральных электрических сетей, включающая 43 системных оператора из 36 стран Европы). Основной задачей в рамках создания профиля было обеспечение совместимости устройств и систем различных производителей на всём жизненном цикле энергообъекта. Разработка профиля началась с создания инструмента для спецификации полного объема областей, функций и сигналов для всех системных операторов, входящих в объединение. Целью работы было создание супер-набора функций и сигналов, охватывающего все функциональные области во всех компаниях с целью последующей трансляции этих требований в МЭК 61850. Разработка инструмента (ISTool) была завершена в 2015 году, в 2016 году члены ENTSO-E вносили через инструмент свои функциональные требования. В дальнейшем планировалась работу по формированию из этого профиля, однако, по имеющейся у нас информации, эта работа была временно приостановлена в связи с недостаточностью финансирования.

• RTE (Франция). Профиль МЭК 61850 RTE был опубликован в 2018 году и в наибольшей степени приближен к рекомендациям по составлению профиля, представленным в техническом отчёте 7-6. Для различных функций защиты в профиле RTE приведены схемы взаимодействия логических узлов и определен набор необходимых для такого взаимодействия сигналов.

• ФСК ЕЭС (Россия). Работа по созданию корпоративного профиля МЭК 61850 ПАО «ФСК ЕЭС» началась в 2016 году в рамках НИОКР по созданию типовых шкафов РЗА и АСУ ТП. Профиль ФСК определяет соответствие традиционных наименований функций РЗА и АСУ ТП и логических узлов стандарта МЭК 61850. Профилем вводятся конкретные типы логических узлов заданных классов, позволяющие дифференцировать схожие функции в разных классах напряжений. Помимо этого профиль ФСК уходит глубже в область коммуникационных сервисов и определяет некоторые параметры передачи сообщений по GOOSE/SV/MMS.

Какие проблемы возникают с профилями и что с этим планируется делать?

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

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

• Во-вторых, описание взаимодействия узлов предполагает описание не только выходных и управляемых данных (объектов данных), но и виртуальных входов. Стандарт для описания виртуальных входов предлагает два варианта: использование объектов данных InRef / BlkRef или использование элемента Inputs в SCL-файле. В рамках второй редакции стандарта планируется детализировать требования в части описания виртуальных входов логических узлов.

• В-третьих, для многих функций в профиле может быть определена множественность входящих сигналов и, как следствие, необходимо определять требования к такой множественности (например, на вход логического узла подаётся строго n сигналов, или возможна подача от 1 до m сигналов, или, например, не меньше k сигналов, а кроме того возможны разные комбинации различных сигналов, например, l сигналов типа 1 и p сигналов типа 2. Соответственно, под каждый из таких вариантов должно быть предложено формализованное описание.

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

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

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