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

• ISAS является аппаратно-независимым решением (т.е. система может быть развёрнута на практически любой машине архитектуры 86_64).
• ISAS работает под операционной системой (ОС) Linux, имеющей специальные патчи ядра для реального времени.
• ISAS обеспечивает возможность реализации различных архитектур, начиная от полностью децентрализованных (т.е. независимые экземпляры программного обеспечения запущены на разных серверах) до полностью централизованной архитектуры (когда на одном сервере запущен один экземпляр ПО, обеспечивающего РЗА всех элементов подстанции) (см. Рис. 1).
• Архитектура ISAS позволяет реализовывать схемы с резервированием, где несколько серверов резервируют друг друга.
• Конфигурирование ISAS на 99% основано на использовании файла SCD (System Configuration Description), который полностью описывает реализуемый комплекс РЗА, включая уставки.
• Мониторинг и оперативное управление осуществляется через панельный компьютер, конфигурирование которого осуществляется файлами, подобными SCL (System Configuration Language) файлам, который обменивается данными с серверами ISAS по протоколу MMS.
• SCADA-система (при необходимости её реализации) подключается к серверам ISAS по протоколу MMS.

Рис. 1. Возможные архитектуры системы ISAS.

Несмотря на то, что данное ПО обеспечивает возможность реализации различных архитектур, наиболее часто встречающейся архитектурой стала полностью централизованная с применением резервного сервера. Также, согласно действующим нормативно-техническим документам, встречаются проекты с отдельными серверами, выделенными для решения задач учёта электроэнергии, регистрации аварийных событий и др. (см. Рис. 2).

Рис. 2. Наиболее распространённая архитектура ISAS.

Мы принимали участие в пуско-наладке 3 проектов с использованием ISAS (полным или частичным):

• Подстанция 110/10 кВ с реализацией РЗА всех присоединений на базе двух серверов с программным обеспечением ISAS с использованием традиционного комплекта дифференциальной защиты каждого силового трансформатора в качестве резервной (далее – Проект №1).
• Подстанция 110/35/10 кВ с несколькими серверами ISAS. ISAS используется в качестве единственной (основной) системы управления, в то время как присутствует резервирование РЗА традиционными комплектами (далее – Проект №2).
• Реализация защиты шунтирующего реактора на подстанции 220 кВ с использованием ISAS (далее – Проект №3).

Рис. 3. Совмещённые ПАДС.

Указанные проекты имеют общие особенности:

• Совмещенные преообразователи аналоговых и дискретных сигналов (ПАДС) устанавливались на открытом распределительном устройстве (ОРУ) и в релейных отсеках комплектных распределительных устройств (КРУ) (см. Рис. 3). ПАДС оснащены набором дискретных входов и выходов, а также аналоговых входов для подключения токовых цепей и цепей напряжения. Они поддерживают публикацию GOOSE и Sampled Values сообщений, а также приём GOOSE сообщений.
• ПАДС, применённые в проектах, имеют модульную архитектуру, что обеспечивает возможность их применения на присоединениях различного типа и различного класса напряжения.
• Для присоединений 110 кВ было предусмотрено применение нескольких (двух) ПАДС для обеспечения надежности. Оба ПАДС подписывались на сообщения от основного и резервного серверов для исключения единой точки отказа.
• На присоединениях 10 кВ применялся один ПАДС.
• В качестве топологии шины процесса использовалась топология двойной звезды с применением протокола резервирования PRP. Для небольших проектов использовался один коммутатор в сегментах ЛВС А и Б.
• Синхронизация устройств по времени осуществлялась с использованием протокола PTP. Функциональность серверов времени обеспечивали коммутаторы ЛВС.
• Для больших проектов предусматривалось применение нескольких панельных компьютеров, обеспечивающих реализацию функций мониторинга и управления (по одному на каждый класс напряжения). Панельные компьютеры, отвечающие за функции управления оборудованием распределительных устройств 10 кВ, располагались в непосредственной близости от распределительных устройств. Панельные компьютеры для управления оборудованием 110 кВ устанавливались в ОПУ.
• В нашем портфеле отсутствовали проекты с применением ISAS для решения задачи учёта или контроля качества электроэнергии. Технически это было возможно, но было ограничено действующими нормативными документами. Проекты отличались друг от друга количеством присоединений, что предъявляло различные требования к требуемым вычислительным ресурсам. В проектах №1 и №3 применялось только 2 сервера (основной и резервный) с программным обеспечением ISAS. Проект №2 предусматривал применение 6 серверов: 4 сервера обеспечивали выполнение функций РЗА, а 2 сервера обеспечивали выполнение функций управления (см. Рис. 4). Также проекты отличались типом используемого аппаратного обеспечения: в проектах №1 и №3 применялись сервера HPE Proliant, в проекте 2 - сервера DELL. Также отличались типы коммуникационных интерфейсов, установленных в серверах (это оказалось важно).

Рис. 4. Серверные стойки ISAS для проекта №2.

Опыт выполнения пуско-наладочных работ

К началу выполнения пуско-наладочных работ проектов с применением ISAS у нас уже был накоплен обширный опыт выполнения наладки комплексов РЗА с использованием стандарта МЭК 61850 на основе традиционных ИЭУ, поэтому мы чувствовали себя достаточно комфортно при решении задач конфигурирования коммуникаций по стандарту МЭК 61850 (GOOSE, Sampled Values и MMS). Мы также обладали обширным опытом по проектированию и конфигурированию ЛВС (включая организацию фильтрации трафика). Также мы уже обладали опытом по наладке и тестированию систем обеспечения единого времени (СОЕВ) на основе протокола PTP. Таким образом, к моменту начала работ мы чувствовали себя абсолютно уверенными в том, что обладаем достаточными навыками для решения поставленной задачи.

Пуско-наладку ISAS можно разделить на следующие этапы:

• Первоначальное конфигурирование серверов, включая установку ПО ISAS.
• Конфигурирование системы с использованием файла SCD, включая развёртывание конфигурации на серверах.
• Конфигурирование ПАС и ПДС.
• Конфигурирование устройств СОЕВ и ЛВС.
• Конфигурирование панельного компьютера.
• Конфигурирование внешней SCADA-системы (при необходимости).

Первоначальное конфигурирование серверов и установка ISAS

Существенным отличием пуско-наладочных работ стандартных ИЭУ от таковых с использованием программной РЗА является то, что в последнем случае аппаратное обеспечение не содержит ни операционной системы, ни какого-либо базового программного обеспечения, и поставляется независимыми организациями. В нашем случае подрядчик приобрёл сервера отдельно от ПО ISAS, то есть сервера не имели никакого предустановленного ПО. На первом этапе на сервер необходимо было установить операционную систему Linux и ПО ISAS, а затем запустить простой демо-проект для того, чтобы убедиться в том, что система работает и готова к развёртыванию полноценной конфигурации. Мы не будем вдаваться в детали всех проблем, с которыми столкнулись, а лишь перечислим их, обозначив основную суть:

• Учитывая требования к работе в режиме реального времени и высокую загрузку процессорных мощностей, ПО ISAS включает так называемые модули ядра, которые глубоко интегрируются в ОС Linux и сильно зависят от версии установленной ОС Linux. Мы были привязаны к определённой версии ядра Linux, поскольку нам была предоставлена предварительно скомпилированная библиотека ISAS.
• Аппаратное обеспечение, которое мы использовали в проектах, было достаточно современным и оказалось так, что некоторые модули (включая модули сетевых интерфейсов) не поддерживались соответствующим ядром Linux. Нам пришлось компилировать драйверы сетевых интерфейсов самостоятельно, используя исходный код, предоставленный производителем сетевого интерфейса. Помимо этого, аппаратное обеспечение, которое использовалось в проектах, также отличалось, соответственно, для каждого проекта требовалось специфичное конфигурирование. На этом этапе нам потребовалась поддержка разработчиков и привлечение собственных программистов для компиляции драйверов.
• Многие программные модули Linux распространяются как пакеты используя соответствующие пакетные менеджеры (такие как apt, yum, rpm и др.). Когда требуется тот или иной модуль, администратор может установить его используя простую командную строку и команду install <<название пакета>>. При обработке данной команды менеджер пакетов выполняет проверки зависимых пакетов и автоматически устанавливает их, если они не установлены в системе. Пакетный менеджер имеет информацию о версии ядра и производит установку соответствующей версии требуемого пакета, совместимой с ядром, поэтому администраторы обычно не задумываются о соответствии версии пакета версии ядра. Обычно, когда требуется установка какого-либо пакета, происходит его загрузка с удаленного репозитория через интернет-соединение, поэтому от администратора не требуется каких-либо дополнительных усилий. Однако в случае с подстанцией интернет-соединение может быть недоступно (особенно для удалённых подстанций) или ограничено (из-за соображений информационной безопасности). Указанное требует дополнительных действий от администратора, поскольку он должен априорно иметь локальные копии репозиториев для определённой версии ядра, что в большинстве случаев не так и, в конце концов, установка происходит в несколько этапов. После загрузки всех необходимых пакетов и модулей, ПО ISAS было установлено на серверах и была готовность к развёртыванию тестового проекта. Далее мы обнаружили, что GOOSE-сообщения от ISAS передавались с некорректным Ethertype (0x0000 вместо 0x88b8). Это потребовало ещё нескольких дней разбирательств и в результате закончилось рекомпиляцией драйверов сетевого интерфейса с другими параметрами.

Вышеописанные этапы заняли у нас около 3 месяцев, после чего мы получили навыки развёртывания ПО ISAS практически на любом аппаратном обеспечении. Наша команда состояла из 3 высококвалифицированных инженеров и одного сеньор-программиста. Теперь мы уверены в том, что для нас решение подобной задачи будет намного проще и не займёт столько времени. Необходимо учитывать, что смена аппаратного обеспечения приведёт к тому, что все описанные операции придётся повторить. И к этому моменту времени специалистам электросетевой компании придётся решать эти задачи либо самостоятельно, либо нанимать компанию с соответствующими компетенциями.

Конфигурация системы ISAS

Как уже было отмечено ранее, ISAS практически полностью настраивается с использованием файла SCD, что очень удобно для инженеров, знающих и разбирающихся в языке SCL и моделях данных по стандарту МЭК 61850. Каждая функция, реализуемая ISAS представлена определенным логическим узлом и все взаимодействия между функциями (включая коммуникации между функциями внутри одного физического устройства) описываются объектами данных InRef логических узлов, принимающих данные. Основным недостатком конфигурирования ISAS стало отсутствие законченного инструментального ПО для настройки. При этом конфигурационные файлы SCL ПТК ISAS предусматривают использование проприетарного синтаксиса, что препятствовало использованию системных конфигураторов сторонних производителей. Таким образом, вся конфигурация была создана вручную (к счастью, в нашем распоряжении был пример уже реализованного проекта, который мы использовали в качестве шаблона). Инженеры, которые хотя бы раз пробовали создавать или редактировать файл конфигурации системы SCD, могут представить масштаб проблемы: финальный файл SCD для проекта насчитывал более 470 000 строк (см. Рис. 5).

Рис. 5. Конфигурационный файл SCD для системы ISAS.

Мы думаем, что перечисленные проблемы конфигурирования являются временными и будут разрешены в ближайшем будущем. По крайней мере, устранение проприетарного синтаксиса позволит использовать сторонние системные конфигураторы, что облегчит задачу конфигурирования системы в целом. Другим значимым аспектом, относящимся к работе с конфигурационными файлами, является управление ими. Поскольку файл SCD становится единственным контейнером конфигурации целой подстанции, он требует особого внимания. В нашем случае мы приняли решение управлять файлом конфигурации по аналогии с исходными файлами в программировании, сохраняя все версии и отслеживая отличия между ними. Мы ощутили все плюсы данного подхода, когда заказчик, внеся изменения в конфигурацию, развернул систему, используя устаревший файл SCD (который хранился на USB-флешке). Указанное привело к существенной деградации системы. Для решения задачи версионирования файлов SCD мы использовали систему Теквел Парк собственной разработки. Данная система позволяет анализировать файл SCL и представлять отличия одной версии файла от другой. Как уже было отмечено ранее, файл SCD на 99% обеспечивает конфигурирования системы ISAS. Однако оставшийся 1% также очень важен и включает в себя назначение серверных ресурсов, что играет значительную роль в обеспечение надежности функционирования системы. Назначение ресурсов должно быть выполнено наиболее оптимальным образом, обеспечивая работу программного обеспечения без прерываний и временных задержек. В нашем случае мы определяли назначение виртуальных ИЭУ на ядра процессора вручную. Мы убеждены в том, что при серийной реализации назначение ресурсов может выполняться автоматически при условии наличия данных по требуемым ресурсам для каждого логического узла, реализуемого на внутри ИЭУ.

Конфигурирование ПАС и ПДС

Несмотря на то, что в настоящей статье этот раздел идёт следом за разделом конфигурирования сервера, конфигурирование ПАС и ПДС выполнялось на предыдущем этапе, поскольку конфигурации данных устройств представлены в файле SCD. В конфигурировании ПАС и ПДС нет никаких отличий по сравнению с любой другой системой, реализованной в соответствии со стандартом МЭК 61850. Коммуникации между системой ISAS и ПАС/ПДС были реализованы исключительно с использованием коммуникационных сервисов GOOSE и Sampled Values. Протокол MMS не использовался на уровне процесса.

Конфигурирование ЛВС и системы обеспечения единого времени

Мы объединили процедуры конфигурирования ЛВС и СОЕВ в один раздел, поскольку в данном проекте некоторые коммутаторы использовались в качестве гроссмейстерских часов PTP. Также требовалось конфигурирование коммутаторов с точки зрения протокола PTP. Никаких особенностей конфигурирования СОЕВ по сравнением с децентрализованными архитектурами с применением протокола Sampled Values не было. Однако конфигурирование коммутаторов Ethernet имело определенную специфику. В первую очередь, количество потоков Sampled Values (например, в проекте №2 их было 192) потребовало определенных мероприятий, поскольку сеть 100 Мбит/с не способна обеспечить передачу такого объёма данных. Более того, если этот трафик не будет отфильтрован и будет перенаправлятся коммутатором на конечное устройство (устройство РЗА, ПАС, ПДС и др.), то это в большинстве случаев будет приводить к отказу в обслуживании со стороны ИЭУ, приводя к тому что последнее не будет способно участвовать в информационном обмене. С другой стороны, сервера ISAS, оснащённые высокопроизводительными коммуникационными интерфейсами с пропускной способностью 40 Гб/с, и архитектура программного обеспечения ISAS позволяют принимать значительное количество по потоков Sampled Values через один коммуникационный интерфейс. Таким образом, в данном проекте коммутаторы выступили своего рода диодами, которые пропускали трафик исключительно на порт, к которому был подключён сервер. Технически это было достигнуто путём задания уникального значения тега VLAN ID для каждого исходящего потока Sampled Values и включения соответствующих портов коммутатора в эти VLAN, а также включением порта коммутатора, к которому было подключено серверное оборудование во все созданные VLAN. Единственной проблемой при реализации такой схемы стал мониторинг и диагностика потоков Sampled Values. Объём трафика Sampled Values в сторону серверного оборудования был настолько велик, что было абсолютно невозможно контролировать его используя какое-либо программное обеспечение, установленное на обычном ПК. Испытательная установка, которую мы попробовали использовать, также не справилась с задачей - она просто теряла кадры Sampled Values. Для решения задачи мониторинга и диагностики потоков Sampled Values мы вновь использовали комплекс Теквел Парк, справляющийся с задачей одновременной обработки до 100 потоков Sampled Values. Это позволило сэкономить время на физических переподключениях в ЛВС и на переконфигурировании сетевого оборудования в рамках пуско-наладочных работ.

Конфигурирование панельного компьютера

Поскольку физических ИЭУ, размещаемых в ОПУ, в составе ПТК ISAS не предусмотрено, мониторинг и управление может осуществляться либо через SCADA-систему, либо через отдельно устанавливаемые панельные компьютеры с тач-панелью (см. Рис. 6). Данный панельный компьютер, на котором установлен соответствующий программный модуль ISAS, обеспечивает выполнение тех же функций, что и человеко-машинный интерфейс обычного ИЭУ: отображение дискретных сигналов, измерений, сигнализации, выполнение операций управления (включая управление первичными аппаратами), изменение значений и групп уставок, отображение журналов событий. Панельный компьютер обменивается данными с серверами ISAS по протоколу MMS.

Рис. 6. Панельный компьютер системы ISAS.

Конфигурирование панельного компьютера имело много общего с конфигурированием сервера ISAS. Мы должны были:

• Подготовить систему: установить ОС Linux и соответствующие библиотеки панельного панельного компьютера.
• Сконфигурировать панельный компьютер с помощью файла конфигурации.

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

Заключение

В результате проделанной работы мы успешно завершили пуско-наладочные работы и на основании полученного опыта можем сделать следующие выводы о программной РЗА:

• Программная РЗА и, в частности, централизованная, является многообещающей технологией, и этому есть весомые доказательства.
• Программная РЗА, которая не зависит от аппаратного обеспечения, обеспечивает чрезвычайную гибкость и открывает интересные возможности использования высокопроизводительных серверов, что позволяет сократить затраты по сравнению со стандартным подходом к построению систем РЗА.
• Пуско-наладка и обслуживание программной РЗА значительно отличается от таковых применительно к традиционным системам РЗА, поскольку специалисты должны обладать навыками администрирования серверов Linux, и это существенно отличается от текущего положения дел.
• Поскольку конфигурационные файлы для подобной системы начинают играть существенную роль в работе системы, они требуют соответствующего отношения: их надлежащие хранение и версионирование является обязательным условием.
• Коммерчески доступные сервера обычно имеют меньший срок службы по сравнению с ИЭУ, что потребует их замены через несколько лет. Этому вопросу следует уделить особое внимание ещё и потому что новое серверное оборудование может быть не совместимо с ранее установленным программным обеспечением.
• Зрелость технологии, с которой нам довелось работать, на сегодняшний день не позволяет приступить к серийной реализации подобных систем, поскольку требует новых знаний и компетенций от разных специалистов: от проектировщиков до эксплуатации.
• Мы ожидаем, что совершенствование конфигурационного ПО, а также развитие прикладных профилей значительно усовершенствует процесс конфигурирование программной РЗА.
• Реализация программной РЗА потребует от электросетевых компаний реорганизации служб РЗА в случае если обслуживание оборудования будет производится их собственными силами.