Сегодняшней публикацией мы открываем серию статей-размышлений о цифровой трансформации в электроэнергетике. Тема действительно актуальная и острая.
Кроме того, данной статьёй мы опробуем новый формат взаимодействия. Если вам есть что сказать об электроэнергетике, присылайте свои материалы, после обсуждения я буду их публиковать с указанием вашего имени или без, по желанию. В этом формате я выступаю как редактор и издатель, но даю площадку для открытого профессионального электроэнергетического диалога.
Данная статья именно в таком формате и выпускается, в ней наш коллега пытается представить, как могла бы измениться система РЗиА с внедрением в неё облачных технологий. На мой взгляд, мысль интересная. Автор открыт к обсуждению, все вопросы пишите в комментариях.
Итак, прекращаю свою болтовню и предоставляю слово коллеге.
Цифровизация - это такое внедрение цифровых технологий, которое кардинально меняет деловые и производственные процессы. На текущем этапе развития информационных технологий в качестве трансформирующих рассматривается целый ряд технологий, например: облачные вычисления, мобильные устройства, социальные сети и другие. Давайте посмотрим, как внедрение облачных вычислений может повлиять на общий облик РЗиА будущего, на процессы внедрения и эксплуатации устройств РЗиА.
Сейчас функции релейной защиты и автоматики реализуются в микропроцессорных терминалах, установленных на объектах электроэнергетики. В каждый терминал поступают аналоговые сигналы с измерительных трансформаторов тока и напряжения. Терминалы самостоятельно оцифровывают эти сигналы и рассчитывают значения величин, не измеряемых напрямую, но используемых в реализованных алгоритмах. На основании измеренных и рассчитанных величин алгоритмы терминала выявляют отклонения в режимах работы электрической сети или признаки протекания каких-то аварийных процессов. По заранее заданным параметрам алгоритмов терминалы фиксируют недопустимые отклонения и формируют выходные воздействия. На каждом объекте может стоять несколько десятков таких терминалов. Чтобы установить такое устройство на объекте сначала нужно выполнить проектирование: определить необходимый функционал, выбрать подходящее устройство с необходимым набором функций, а определившись с устройством, разработать чертежи, которые позволят установить и подключить это устройство на объекте. По разработанным чертежам устройство нужно смонтировать. Смонтированное устройство нужно ввести в работу, для этого выбираются и задаются в устройстве параметры его настройки, уникальные для данного конкретного места в электрической сети, после чего проводится ряд проверок с целью убедиться в правильности монтажа и функционирования устройства. Только после всего этого терминал можно ввести в работу. Весь процесс проектирования, монтажа и ввода в работу обычно занимает несколько лет. Но и на этом всё не заканчивается, каждое из установленных устройств нужно периодически проверять, иногда приходится менять заданные ранее параметры или алгоритмы функционирования, а то и вообще всё устройство. Стоит ли говорить, что всё это требует огромного количества ресурсов, а в итоге — денег.
Облачные вычисления предполагают, что у потребителя их результатов нет аппаратного устройства. То есть вычисления выполняются на арендуемых на время мощностях. Необходимые для проведения вычислений мощности выделяются из вычислительного пула, реализованного на группе компьютеров — кластере. Этот кластер и называется облаком. Как же можно внедрить облачные вычисления в РЗиА? Как можно поставлять функцию защиты без физических устройств? Для реализации функций РЗиА в облаке потребуется оцифровывать на объекте и передавать в облако все измерения выполняемые на объекте, что потребует высоконадёжных каналов связи с фантастической пропускной способностью, ведь каждый измерительный преобразователь будет формировать сотни мгновенных измерений в секунду. А это кажется совсем уж фантастичным. Таким образом получается противоречие, с одной стороны, мы хотим выполнять функцию в облаке, чтобы избавиться от дорогой аппаратуры, но при этом нам нужны крайне дорогие каналы связи. Понимая имеющееся противоречие, давайте посмотрим, что предлагает IT индустрия для его разрешения? Чтобы разрешить это противоречие, целесообразно вынести вычисления, потребляющие большой объём входных данных, ближе к источникам этих данных. Это называется Edge computing (или иногда ещё fog computing) — облачные вычисления с вынесением их части на устройства, приближённые к генераторам и потребителям данных. При этом такие вычисления могут выполняться как на отдельных устройствах, так и на небольших локальных вычислительных кластерах. Вот так мы переизобрели “Цифровую подстанцию” (ЦПС). Цифровая подстанция сейчас имеет несколько возможных уровней реализации. В переходном варианте она предполагает отдельные устройства, устанавливаемые на тех же местах, что и традиционные терминалы РЗиА, и обменивающиеся между собой сообщениями, но окончательной реализацией ЦПС является вычислительный кластер, установленный непосредственно на объекте, собирающий все измерения и реализующий все функции защиты и автоматики объекта.
Хорошо, мы переизобрели ЦПС. Понятно, что функции защиты пока что вынуждены исполнятся на устройствах в непосредственной близости от места измерений и реализации воздействий, будь то отдельные устройства с единственной функцией или единый на весь объект вычислительный кластер. Но что тогда можно вынести на удалённое облако? Да, пожалуй, почти всё остальное: настройку, диагностику, регистрацию аварийных событий. Например, имеется единое приложение РЗиА запущенное в облаке, и вовсе не обязательно публичном, пусть это будет облако, развёрнутое на вычислительных мощностях самой сетевой компании или контрактного поставщика услуг. В этом приложении есть доступ ко всему функционалу РЗиА на всех объектах сетевой компании. То есть, войдя в такое приложение, персонал может ввести, вывести, настроить любую функцию, посмотреть журналы работы любого устройства или посмотреть осциллограммы аварийных событий по любому событию, в том числе с разных объектов одновременно. Больше не нужно ехать на объект, выводить из работы устройство, подключаться к нему, скачивать с него файлы, закачивать файлы на него, как-то эти файлы хранить, как-то ими обмениваться. Теперь при обеспечении функций РЗиА нет устройств, есть только сами функции, доступные в одном месте. Конечно, сами устройства никуда не делись, но они отделены от функционала, они не выполняют заранее заданный набор функций, а выполняют только те, которые им делегировало облачное приложение.
Заманчиво смотрится возможность изменять настройку, а то и алгоритмы функционирования без выезда на подстанцию, вывода устройства в ремонт, да даже без перезагрузки самого конечного устройства. Вот так, например, зашёл сотрудник в “облачный” АРМ (автоматизированное рабочее место), увидел свежее обновление алгоритма от производителя, выбрал интересующее устройство и нажал “обновить”. Проходит несколько минут и новый алгоритм уже работает на конечном устройстве.
В описываемом светлом будущем мы будем иметь четыре вида поставщиков: поставщиков аппаратных конечных устройств, поставщиков облачных платформ, поставщиков облачных приложений и поставщиков алгоритмов РЗиА.
Аппаратные устройства будут устанавливаться на объектах электроэнергетики и выполнять алгоритмы, потребляющие большое количество данных. Это могут быть как отдельные терминалы, так и местные вычислительные кластеры. Выполняться на них будут в первую очередь алгоритмы релейной защиты, требующие быстрой обратной связи и использующие мгновенные значения тока и напряжения, то есть потребляющие большие потоки данных, и алгоритмы выполняющие дорасчёт дополнительных величин.
Облачные платформы будут представлять собой программно-аппаратные комплексы, устанавливаемые в центре обработки данных. Это может быть центр обработки данных самого поставщика, мощности которого будут сдаваться в аренду. Такой вариант может быть выгоден небольшим сетевым компаниям, не имеющим возможности развернуть свою облачную инфраструктуру. Крупные же сетевые компании скорее всего развернут облачную платформу в собственном центре обработки данных на основе решений, предоставленных поставщиком. Задача облачных платформ — обеспечить быстродействующую отказоустойчивую среду для выполнения облачных приложений.
Облачные приложения — это все те программы, которые будут управлять работой аппаратного обеспечения объектов электроэнергетики, выполнять их настройку, обновление, мониторинг, выполнять некоторые алгоритмы автоматики или их части. Облачным приложением будет АРМ релейщика, облачным сервисом будет приложение, собирающее и накапливающее осциллограммы аварийных событий, журналы работы устройств.
Алгоритмы РЗиА это, собственно, не зависящая от железа, и окружающей программной среды реализация алгоритмов защиты и автоматики. Часть этих алгоритмов, как уже говорилось, должна выполнятся на устройствах, установленных на объектах, так как потребляет огромное количество первичной информации и обеспечивает предъявляемые к ним высокие высокие требования по времени отклика. Другая часть, например, некоторые алгоритмы противоаварийной автоматики, может выполняться в облачной среде, так как к ним предъявляются меньшие требования по быстродействию, чем к релейным защитам, но зато, находясь в облаке, они могут получить доступ к большему объёму данных и большему объёму вычислительных ресурсов, что позволит точнее оценивать схемно-режимную ситуацию и реализовывать более эффективные управляющие воздействия.
Чтобы обеспечить возможность совместной работы программных и аппаратных решений разных производителей, нужно будет провести работу по стандартизации среды исполнения для программных решений. Вероятно, также потребуются какие-то кроссплатформенные трансляторы для программ и алгоритмов.
Нельзя обойти вниманием и законодательство. Сейчас вся существующая и разрабатываемая нормативно-техническая документация (НТД) рассматривает микропроцессорное устройство РЗиА (железо и выполняемые функции) как неделимое и неизменяемое решение. Для замены программного обеспечения НТД требуют разрабатывать проектную и рабочую документацию, что странно, так как технически заменить прошивку ненамного сложнее, чем обновить приложение на смартфоне. Даже разрабатываемые проекты цифровых подстанций и оборудования для них рассматривают терминалы как неделимые программно-аппаратные решения. Следует разделить требования НТД на требования к аппаратному обеспечению терминалов и требования к алгоритмам. Таким образом, требования к аппаратному, и системному программному обеспечению стали бы включать такие общие требования, как количество и тип входов и выходов, требования к протоколам работы цифровых портов, требования по электромагнитной совместимости, требования по быстродействию и времени реакции, требования к системной среде исполнения. Требования же к алгоритмам стали бы включать, в первую очередь, требования к совместимости со стандартной средой исполнения, а уже затем, требования к конкретным видам алгоритмов, разделённые по видам выполняемых функций РЗиА.
Такие решения позволили бы значительно упростить разработку, внедрение и эксплуатацию РЗиА. Например, разделение аппаратной и программной платформ может помочь обеспечить аппаратную совместимость устройств в пределах объекта и одновременно функциональную совместимость в пределах ЛЭП. Вынесение сервисных функций, обеспечивающих обслуживание программной части системы РЗиА в единое облако, поможет упростить анализ аварийных событий, анализ сбоев в работе алгоритмов, их оперативное исправление и обновление.
Именно такие решения, такое внедрение цифровых технологий, которое кардинально меняет деловые и производственные процессы, и можно назвать Цифровизацией.