Цифровые подстанции – первые практические итоги. До сих пор не утихают дискуссии об экономических эффектах применения цифровых подстанций в сравнении с традиционными решениями, наиболее оптимальных архитектурах как с точки зрения вторичного, так и с точки зрения первичного оборудования. Изменение парадигмы проектирования, как ключевая веха в переходе к цифровым подстанциям
- Цифровые подстанции - первые практическин итоги.
- Какие преграды существуют сейчас при реализации проектов ЦПС?
- Система поддержания жизненного цикла ЦПС. Проектирование, приёмка, эксплуатация.
- Практические вопросы создания цифровых проектов.
- Применение открытых онтологий для проектирования и эксплуатации цифровых подстанций.
И так начнём. Архипов Игорь Леонидович, в рамках презентации расскажет о первых практических итогах по реализации ЦПС. Прошу.
Сложность релейной защиты росла и аналоговыми технологиями она уже не вытягивалась. Началось внедрение технологий МЭК-61850. В компании по магистральным сетям, где системы были значительно сложнее, это началось это немного раньше. Соответственно, где-то с 2003-2005 годов началось активное внедрение МЭК. То, что мы сегодня называем первой архитектурой, то тогда таких пониманий у нас не было. Но где-то в 2015-ом году при формировании программы инновационного развития мы вместе с коллегами из релейной защиты проанализировали весь тот опыт, который был нами наработан при реализации порядка 100 объектов, с применением отдельных элементов с 1-й, частично с 2-й архитектуры, как мы договорились позже.
Мы поняли, что надо развивать внутреннюю компетенцию, внутреннюю стандартизацию. И надо где-то все это испытывать, надо каким-то образом сопровождать технические требования к этим системам и мониторить их. Эти основные четыре вектора были продуманы и по ним начаты НИР. Частично они легли в основу стандартов организации. Слайд 1.1.
Был создан полигон на базе «НТЦ ФСК», и в году 2013-м активно начали на этом полигоном работать. С 2015-го года вместе со специалистами служб РЗА началась работа по разработке комплекса стандартов по ЦПС. Основной вектор – это типизация решений 110 и выше, разработка системы паспортизации и системы мониторинга системы релейных защит, разработка системы для тестирования и приемки ПТК из наладки. В 2016-м году получили определенные бумаги по проведению испытаний на нем, которые показали, что испытания комплексов ЦПС, отдельных решений – это большая трудоемкая процедура, которая зачастую затягивала развитие этой технологии и вывод новых решений на рынок. Такого рода НИР были проведены и на сегодня разработано порядка 30-ти стандартов, которые открыты и сайтах «Россетей» и «ФСК» опубликованы. В этом году вышли базовые документы по проектированию, по корпоративному профилю. Несмотря на то, что мы получаем много критики на эти стандарты, но двигаться дальше без них невозможно. Опыт показал, что это некий ключевой этап, пройденный нами. В 2012-м году журнал «Цифровые подстанции» проводил конференцию «Правила проектирования цифровых подстанций». Там была развилка. В тот момент по магистральным сетям было прописано требование о необходимости при проектировании применения SV и прочих вещей, что было встречено всем сообществом достаточно тяжело. До сих пор, наверное, все до конца не выработали механизмы, каким образом это сопровождать.
Тем не менее, система проектирования и управления всего жизненного цикла вообще, у нас ведется по разным направлениям, в том числе по вторичной коммутации. Постараюсь выложить на слайле 1.2.. Мы видим целиком цифровизацию инжиниринга, и вторичная коммутация туда укладывается, как один из элементов.
Планы. Короткий слайд 1.3.. Это отработка всех видов архитектур.
Отдельный вопрос по распредсетям. Для них придется формировать 4-ю, возможно какую-то 5-ю архитектуру. Решения по ним достаточно более быстро развиваются. Часть НИР направлена в эту плоскость.
Вот перечень НИОКР и работ (Слайд 1.4.), которые проводятся в группе компаний. Часть этих работ завершена, часть легли в основу нормативки, либо отдельных сервисов. Само же движение в области ЦПС будет обрастать IT-сервисами по их проектированию, наладке, защите и мониторингу, а так же сопровождаться ростом нормативной базы. Конечно, у нас значителен скачок в области построения АСУТП, и то, что мы сейчас называем ЦПС, от стандартизации уровня, например, 5-летней давности до сегодняшнего дня. То есть с единиц документов до полусотни сегодня.
Что касается технологической части, то Андрей Сергеевич расскажет по опыту подстанций «Тобол», «Медведевская», «Ладушкин», с которой он недавно приехал. Если есть вопросы, то готов ответить.
Модератор: На ваш взгляд, на что нужно обратить наибольшее внимание в ближайшие три года в рамках цифровой подстанции? Расширять, продолжать такими же темпами, расширять «нормативку» или что-то иное? Архипов Игорь Леонидович: Особое внимание к проработке дополнительных архитектур по распределительным сетям, унификации решений, типизации по этому направлению и выработка нами таких модульных решений, чтобы можно было подстанцию завозить. Лет 10 назад мы мечтали, что МЭК-61850 должен быть из серии Plug&Play – привез, включил, работает. Само настроилось. Наверное, по этому пути нам и придется идти, который будет сопровождаться расширением «нормативки» применительно к нашим углам и проблемам. Модератор: Отлично. Андрей Сергеевич, я прошу вас дополнить доклад Архипова Игоря. Ваша текущая оценка ситуации с ЦПС. Довольны ли? Какими темпами сейчас все идет? Какие преграды вы сейчас встречаете перед собой при реализации проектов ЦПС?Что касается дальнейших действий, то да, типизация однозначно. Я всегда говорил что ЦПС, если она жестко не регламентирована, не типизирована, то это мина замедленного действия с обязательным взрывом. Почему? Смотрим на электромеханику. Чтобы сделать новую функцию нужно найти несколько реле. Установить на панели, пробросить кабели и т.д. и т.п. В микропроцессорные защиты нужно ввести функции – проблем нет. Но найти выходные реле и дискретные входы, которые обеспечат работоспособность этой функции, пробросить кабель – затруднительно, но уже легче. Связь? Пожалуйста. И пробросить сообщение с 10 кВ на 500 кВ и отключить – да не проблема. Это вопрос фантазии проектировщика и наладчика. Как следствие, мы сейчас находимся в ситуации, не до конца понимая ситуацию с проблемами, которые возникают с 3-й архитектурой, я имею в виду SV-потоки. Я понимаю проблемы в синхронизации времени PTP, их реализации. Только что проводил совещание по «Тоболу» и там у нас вроде бы все хорошо. Мы резко снизили количество каких-то сбоев, выбросов больше нет, трансформаторы «ПРОФОТЕК» работают нормально, но синхронизация времени сбоит примерно 5-7 раз в месяц. Много это или мало?
С точки зрения работы трансформаторов тока по «ФСК» это абсолютно недопустимо. Если электромагнитный трансформатор тока пересчитает на повреждения, то теоретически ему нужно ждать там, по-моему, 1,5 или 2 тысячи лет в «ФСК», чтобы обязательно взорваться или обязательно выйти из строя. Средняя вероятность по «ФСК».
А здесь мы периодически имеем сбои всего комплекса.
Дальше. Я считаю, что вышел достаточно хороший документ с компанией «Теквел». Мы 2 года делали проектирование ЦПС «Ладушкин», то есть мы делали СТО (прим. СТандарт Организации) для проектной документации. Но делать ее для рабочей документации и попробовать посмотреть в том же формате «рабочку» у меня, честно сказать, не получилось так, как я хотел. То есть быстро, внятно осознать все связи, которые там есть, у меня не получается. Поэтому, как сделать рабочую документацию на цифровую подстанцию так, чтобы ее потом передать эксплуатации, чтобы уже она вела исполнительную документацию? Как наложить GOOSE, SV-потоки на виртуальную сеть VLAN ЛВС – это вопрос, который нигде не решен. И я все больше убеждаюсь, что этот вопрос будет отображаться в цифровой рабочей документации без использования бумаги, потому что на бумаге ее не отобразить в принципе, от слова совсем. Точно также, как мы сейчас не печатаем с вами уставки, параметры срабатывания, конфигурационные файлы, а смотрим их именно в конфигурационных файлах в терминалах РЗА, точно также видимо придется смотреть рабочую документацию на цифровые подстанции. Как она будет выглядеть? Пока не знаю. Только предполагаю. Есть наброски. Каким образом это делать? Надо думать. Это основная проблема. По одной простой причине. Если вспомнить старинные панели ПЗ-2/2, ПЗ-157, внутри которых был горизонтальный плоский монтаж, и можно было отследить каждый провод для нахождения неисправности, то в ЦПС такой подход к ремонту не подходит. А что имеем в ЦПС, если отображать чисто физику. Вот софт, вот блок питания терминала, вот из терминала вышло 2 ЛВС, 2 патч-корда в шину станции, шину процесса и все. Вот вся ЦПС. Но то, что над этим физическим уровнем существует программное обеспечение, причем достаточно разветвленное, об этом мы в общем-то периодически забываем.
Отдельной строкой хочу сказать про обучение персонала. Персонал во многом не знает и не понимает до конца тонкостей работы ЦПС, влияние того же сервера времени, VLAN и так далее, на работоспособность системы комплекса. То есть нельзя сейчас отделить ЛВС от РЗА, сервер времени от оптического ТТ и так далее. Это все единый механизм, который должен правильно функционировать. Поэтому обучение персонала – это очень актуальная вещь, которой необходимо заниматься.
Что касается цифровизации комплексов РЗА, эксплуатации, то уже Игорь Леонидович сказал о том, что у нас сейчас создаются три программных продукта – это ПТК «Эксплуатация», ПТК «Электронный каталог РЗА САПР» и ПТК «Приемка». Все эти три программных продукта должны быть завязаны у нас в единую информационную модель, взаимодействовать не с помощью бумажки, а с помощью цифровых моделей данных на основе МЭК-61850 или еще как-то и обмениваться информацией друг с другом. Как раз это и позволит нам минимизировать ошибки при передаче информации, минимизировать время и сделать цифровую энергетику цифровой в части обмена информацией, создания единого информационного поля.
Модератор: Один из зрителей спрашивает: «Использование подстанций во 2-й и 3-й архитектуре требует от эксплуатирующего персонала знаний в новой плоскости. Ведутся ли сейчас какие-либо работы по переподготовке персонала?»Игорь Леонидович нам сказал про большой объем внедряемых объектов, и я хочу еще раз зафиксировать, что согласно его презентации будет создано еще 175 цифровых подстанций в период до 2025-го года. С персоналом планируется что-то делать, Андрей Сергеевич?
Шеметов Андрей Сергеевич: Персонал, как я уже сказал, это одна из основных проблем. При этом я осознаю, что персонал не будет обладать большим количеством знаний, чем раньше. То есть мы с этого персонала, не будем требовать к примеру, вопросов устранения самохода по напряжению реле направления мощности серии РБМ 178, но в тоже время мы должны с него потребовать знания в части GOOSE-сообщений, работы ЛВС и возможности вывода. Алексей Аношин, наверное, более подробно скажет, как у нас идет СТО эксплуатации ЦПС, который должен хотя бы частично решить этот вопрос. Мы думаем обо всем этом, смотрим, анализируем, что можно сделать для того, чтобы получить некие системы распространения этих знаний, потому что отсутствие компетенций персонала – это основной сдерживающий фактор. И об этом говорится везде. Иностранцы тоже об этом говорят. Модератор: Вопрос в продолжение темы. А что делать проектировщикам? О них вы планируете подумать или думаете? Шеметов Андрей Сергеевич: Как человек, который руководил проектной организацией, конечно, да. Думаем. Электронный каталог РЗА, по которому у нас сейчас ведется обучение, то он, конечно, умеет очень мало. Пока он может создавать лишь схему электрическую принципиальную, схему ИТС, делать оперативную блокировку, делать перечень сигналов АСУТП, создавать SSD файл, создавать схему уставок. Пока так. Но планируем к 2022-му году сделать и показать электронный каталог РЗА, который будет уже иметь на своем борту создание схем, точнее томов ПД – это РЗА, ПА, АСУТП, СОПТ. Четыре тома ПД по каждому объекту выдавать в стандартном виде. В дальнейшем, где-то в 2023-й, 2024-й году, наверное, дойдем до рабочей документации. Пока что выпущено СТО по проектированию ЦПС, которое хоть как-то регламентирует такую вещь, как проектирование и дает хоть какую-то основу. При этом «Системный оператор» хотя бы сказал, что да, мы будем принимать документацию по ЦПС в соответствии СТО «Проектирование ЦПС ПАО «ФСК ЕЭС». Хотя бы что-то есть, что говорит о начале пути. То, что подлежит своевременной замене и корректировке, то будем менять, доделывать, совершенствовать. Но в условиях, когда вообще ничего нет, выпуск этих СТО был вынужденный шаг, мы торопились с «Теквел» как могли, но откровенный полуфабрикат тоже не хотелось выпускать.Так что мы думаем обо всех аспектах цикла производства и эксплуатации комплексов РЗА.
Модератор: Вопрос от коллег: «Вы упомянули некоторые проблемы с «ПРОФОТЕК». Есть и у вас план, как победить вопрос синхронизации и есть ли понимание в чем конкретно проблема в рамках этого контура или это вопрос исследования?» Шеметов Андрей Сергеевич: Прежде всего, это вопрос исследования. План? Надо работать по плану: данные есть, осциллографы есть, будем ставить, будем смотреть, будем анализировать. Что могу сказать? Основные сбои, лежащие на поверхности мы прошли, и работа происходит достаточно стабильно и неправильная работа РЗА по вине оптических ТТ уже долгое время уже не наблюдается, а это уже хорошо. Самое главное — это вопрос в причине проблемы с синхронизации. Это вопрос или сервера времени, или ЛВС, которая пропускает PTP-посылки или не пропускает, это вопрос приемника, который является источником SV-потоков, который должен синхронизироваться. Вот этот вопрос мы должны выяснить. Модератор: Поступило еще несколько вопросов. Будем по порядку. Соответственно, опять же я упомянул 175 проектов цифровых подстанций, при этом практически 50% планируется реализовывать по 2-й архитектуре, но эта информация из презентации Игоря Леонидовича Архипова, вот, примерно 20% по 1-й и оставшаяся часть по 3-й архитектуре из 175. Соответственно, вопрос: «На ближайшие три года вы ставку на какую архитектуру лично делаете? То есть помимо опыта «Тобола» еще где-то 3-я будет?» Шеметов Андрей Сергеевич: Да. Будет. Коллеги, давайте проговорим о том, зачем и почему создавались три архитектуры. 1-я архитектура создавалась по двум причинам. Во-первых, потому что благодаря ей мы сумели согласовать вторую и третью с «Системным оператором». Без нее мы бы этого не сделали ни за что. Это основной вопрос. Во-вторых, 1-я архитектура это подстанции, на которых уже установлены микропроцессорные защиты и установка на них 2-й и 3-й архитектуры нецелесообразна. Поэтому расширение подстанции с микропроцессорными защитами (МП) будут идти по пути внедрения шкафов 1-й архитектуры.Есть 2-я архитектура, которая за счет того, что мы перенесли GOOSE в шину станции из шины процесса, позволяет нам, не создавая шину процесса, то есть без дополнительной финансовой нагрузки, обеспечить 2-ю архитектуру достаточно приемлемой по цене, а на больших подстанциях она уже становится рентабельной. И я читаю, что на ближайшие 10 лет 2-я архитектура будет основной архитектурой, с которой мы будем работать.
3-я архитектура — это то, что будет в будущем. Для того, чтобы она пришла, я имею в виду оптические ТТ, цифровые ТН. Нужно, чтобы хотя бы 250 фаз 4 года проработало, и мы бы посмотрели эффект. А сейчас у нас 6 фаз 500 кВ ТТ и 6 фаз ТН. Ну сколько они должны проработать, чтобы накопить опыт? То есть мы должны выходить на то, чтобы внедрять. Есть у нас проекты и на юге, и на Урале, в которые мы будем внедрять оптические ТТ с одной целью – отработка технологии. То, что за ними будущее – это однозначно. Опыты КЗ и опыт постановки АТ под напряжение, на «Тоболе» имеется в виду, показывают, что за ними, за цифровыми технологиями будущее. Как долго пройдет этот процесс - не знаю. Но я уверен, что при определенном вложении средств и масштабе объектов, мы получим опыт, позволяющий внедрять 330 кВ и выше все оптические ТТ. Поэтому так примерно и будет.
Модератор: Замечательно. И еще один вопрос. Сегодня, вы говорили про подстанцию «Ладушкин», по которой рабочая документация в том виде, в котором она была вам предоставлена, вас не устроила. Она была непонятная. Эта документация делалась с использованием какого-либо САПРа? Шеметов Андрей Сергеевич: Нет. Это документация сделана без САПРа. Более того, ни один из современных инструментов, ни «Инжиниринг ПС», ни «Eplan», ни «ECube» в настоящий момент не готовы к МЭК-61850. Они не готовы на переход GOOSE и SV, отображение GOOSE и SV. «Eplan» заявил, что они думают над тем, чтобы в ближайшем будущем написать ТЗ на то, чтобы когда-нибудь что-нибудь сделать. Я думаю, что мы это увидим вообще непонятно когда, с учетом четких, ясных критериев и временных согласований. Поэтому сейчас ничего такого нет, но надеюсь, что может быть мы к 2023 или 2024 году что-нибудь создадим. Модератор: То есть, по-хорошему ЦПС «Ладушкин» была сделана без SSD, без SCD. Шеметов Андрей Сергеевич: Нет, SCD было, но поймите правильно, SCD – это форма предоставления комплексной информации. Большинство релейщиков о чем мечтают. Представьте, что у вас отключился выключатель, и после этого он не включается. На 33-м конце постоянно присутствует плюс. Раньше брали схему и смотрели, что на него действует. На него действует раз – выходное реле, два – выходное реле, три – начинали разбираться с какого выходного реле приходит. Значит, сработали защиты, а какие защиты могут сработать? Такие и такие. Вот нашли функцию, нашли там реле или функцию в терминале, которая сработала и действует на процесс отключения или зависла, или еще что-то. Здесь как быстро найти тот GOOSE, который в ПДС пришел и действует на отключение непрерывно. Вот большой и неоднозначный вопрос. То есть на сегодняшний момент такой визуально понятной и простой схемы, чтобы дойти от GOOSE, действующего на отключение, до оптического ТТ, SV-потока, который это вызывает, сейчас нет. А те табличные формы, которые сейчас есть и которые, кстати говоря, надо признать, в общем-то, инициировал я для проектной документации, они абсолютно не могут использоваться для того, чтобы оценить объем, оценить какие-то требования к шкафам, к ЛВС пропускной способности, еще что-то. Надо думать. Модератор: Андрей Сергеевич, большое спасибо! Вопросы к нам еще приходят, поэтому давайте еще послушаем доклады и возможно часть вопросов оставим для круглого стола, потому что вопросы касаются непосредственно и проектных решений, как таковых. Поскольку была упомянута компания «Теквел», то я бы хотел попросить Аношина Алексея Олеговича подробнее рассказать про жизненный цикл и как с ним работать. Алексей, прошу.Весь жизненный цикл ЦПС с точки зрения эксплуатирующей организации, сетевой компании, логично увязывать в некий единый процесс. В программировании этот процесс называется DevOps, когда непрерывно пишется программный код, тестируется, отдается в продакшен пользователям, там собираются ошибки и комментарии от пользователей и они здесь как бы в этом едином цикле. Это вот постоянный цикл. В этом смысле работа над подстанцией, как нам видится, должна быть примерно в таком же виде.
Если мы посмотрим на ЦПС с точки зрения жизненного цикла, то в этом случае очень сильно меняется парадигма. В проектировании мы перестаем чертить на бумаге. Мы создаем цифровые модели. В наладке мы перестаем вручную переносить цифры из бумаги в терминалы или контроллеры и перерисовывать, скажем, логические диаграммы, мы просто загружаем конфигурацию из проекта в терминалы. И в наладке мы вместо того, чтобы делать планово-предупредительные ремонты и техобслуживание раз в три года, мы просто переходим к тому, что мониторим состояние системы в работе 24 на 7. И каждое отклонение от нормы мы фиксируем и уже по факту наличия такого отклонения предпринимаем какие-то действия. Очевидно, что у такого подхода целая масса преимуществ, которые выражаются в сокращении операционных затрат сетевой компании. Ожидаем, что оптимизация того или иного рода приведет к сокращению и капитальных затрат тоже. Будем реалистами, сейчас капитальные затраты ЦПС, плюс-минус, находятся в том же русле, в котором были и для обычных подстанций.
В этой части мы считаем, что важнейшим элементом являются файлы SCL, так называемые файлы электронной конфигурации электронных моделей, которые насквозь пронизывают весь жизненный цикл объекта от стадии общих технических решений (ОТР) до стадии рабочей документации и во всем цикле эксплуатации этот файл конфигурации живет вместе с подстанцией. Унификация этого интерфейса передачи конфигурации из проекта в эксплуатацию и постоянный контроль актуальности соответствия этого файла тому, что на объекте происходит, внесение изменений в него по мере того, как конфигурация меняется, это чрезвычайно важно. Потому что именно это обеспечит возможность создавать подстанции на базе разных производителей, что тоже очень важно. Мы как бы говорим об электроэнергетике, а подстанции, как сборные солянки, разных производителей и возможности вот открытого рынка для всех. Именно наличие единого интерфейса конфигурации, единых правил конфигурирования обеспечивает создание объектов по принципу Plug&Play, когда не приходится долго сидеть и руками что-то налаживать. Для этого файл конфигурации должен быть единым интерпретируемым всеми. Тогда у всех будет одинаковая семантическая привязка сигналов к жизни. Для проектировщика – это будет таблица сигналов, которые куда-то передаются. Для наладчика – это будет контроль передачи сигналов в текущем времени и возможности их симуляции с помощью программных продуктов, с помощью специальных аппаратных средств. Для эксплуатации – это знакомые им аварийные осциллограммы, журналы событий и так далее. Один и тот же сигнал у всех называется одинаково. Я уже не говорю о дальнейших возможностях всего этого – создание BIG-даты, предиктивной аналитики и всего остального, без единства наименований всего и без единства конфигурации это очевидно будет сделать невозможно.
Важной вехой в этой части явилась работа, которую «ФСК» Андрей Сергеевич Шеметов лично курировал и продвигал, это создание так называемого профиля – стандарта МЭК-61850, который задал единство наименований для сигналов, по крайней мере, в пределах «ФСК». Сейчас эта работа экстраполируется на «Россети» в целом. И единство правил применяемых для протоколов передачи данных во многом необходимо для того, чтобы исключать ошибки. То есть на этом этапе развития наработанный опыт закладывается в виде нормативных требований, чтобы исключить эти ошибки в будущем. Мне, кажется, для дальнейшей дискуссии этого будет достаточно. Готов на вопросы ответить.
Модератор: Алексей, у меня вопрос. Андрей Сергеевич, когда упоминал про жизненный цикл ЦПС, говорил о необходимости того, чтобы все программное обеспечение работало с одинаковыми файлами, одинаково их интерпретировало, и как вы сказали, все это планируется собрать в общую информационную модель и поднять на уровень CIM (прим. Command Information Module), который определяется отдельной серией стандартов. Ваше мнение, нужно ли выносить файл электронной конфигурации цифровых подстанций за пределы МЭК-61850 и поднимать его выше? Аношин Алексей Олегович: Ну я же не сетевая компания. Модератор: Нет. Ваше мнение. Алексей, ведь вы приняли активное участие в разработках в типизации сигналов, протоколов, поэтому интересно ваше мнение о том, нужно ли дальше еще интерпретировать данные с SCL файлов в XML.RD, в CMA или нет? Аношин Алексей Олегович: Если есть задача систематизировать на верхнем уровне данные с групп объектов, то, наверное, целесообразна и привязка отдельных или всех сигналов к какой-то объектной модели верхнего уровня. Вопрос в том, в каком виде это должно делаться и для каких целей. Я небольшой специалист конкретно в CIM, для меня это скорее описание активов, нежели каких-то сигналов. Но даже если мы имеем привязку, скажем, выключателя, как элемента Simak, к выключателю, как элемента SCL файла, то уже с точки зрения IT-системы, этой связи будет достаточно для того, чтобы в дальнейшем состояние этого выключателя отслеживать как с точки зрения управления активами, так и с точки зрения мониторинга текущего режима и контроля работ релейных защит. Модератор: Хорошо. И еще один вопрос от меня. Была проведена большая работа по нормированию сигналов и по применению протоколов. Соответственно, это работа на конечный файл SCD и на все файлы, которые из него можно получить. А с точки зрения SSD файла, который по всем канонам является первым при разработке проектов ЦПС, достаточно ли положений в МЭК-61850, учитывая, что профиль «ФСК» отсылает нас ко второй редакции этого стандарта, или его нужно опять же расширять, увеличивать объемы данных, точнее типизировать информацию, которая туда должна заноситься. Аношин Алексей Олегович: Эта работа сделана уже в рамках, в том числе той работы, которая делалась в «ФСК». Одной из частей этой работы была, так мы это называем, спецификация требований при формировании SSD файла, то есть спецификация того, как именно с использованием в «Semantic 61850» описывать элементы однолинейной схемы, элементы схем электрической принципиальной, которые есть в «ФСК» и в «Россетях» в частности. И здесь МЭКа было достаточно для того, чтобы это описывать. Просто было необходимо конкретизировать отдельные моменты, например, как правильно описывать элементы, которые с помощью МЭК можно описать двумя вариантами, как пример, как описывать корректно трехфазные выключатели или пофазный выключатель (однофазные), как правильно описывать выключатель со встроенными ТТ, силовой трансформатор со встроенными ТТ и так далее и тому подобное. Есть, скажем, пласт таких вопросов, с которыми широкая масса специалистов не сталкивается, но те, кто занимается проектированием уже конкретно, рано или поздно с такими вопросами сталкиваются. Эти вопросы были проработаны как раз в части работы типовых шкафов «ФСК ЕЭС», они были определены и вошли в основу работы, которую делали наши коллеги, кто делал, собственно, ЭК РЗА (Электронный каталог РЗА), который SSD файл формирует в соответствии с этой спецификацией.Если посмотреть в эти нормативные документы, я провел сравнение по нескольким параметрам, соответственно, первое – это какой объем файлов электронной документации в этих документах определяется. В МЭК-61850 в явном виде сейчас определены 6 файлов в опубликованных редакциях. В корпоративном профиле определены те же самые 6 файлов формата SCL. Методические указания, что логично, относятся туда же. В цифровом питающем центре отсылки только на 2 файла – это SSD и SCD, и каких-либо других отсылок нет. При этом, если смотреть на редакции стандарта МЭК-61850 и нормативные документы, которые сейчас опубликованы, то появились редакции некоторых глав стандарта под номером 2.1. Соответственно, корпоративный профиль «ФСК» ссылается на вторую редакцию стандарта, которая сейчас безусловно является актуальной. И при этом за время существования МЭК-61850 официально опубликовано четыре SCL схемы, в соответствии с которыми должны формироваться файлы электронной документации и в настоящий момент 2007В4 является актуальной, корпоративный профиль ссылается на схему 2007B4, которая сейчас также актуальна, но МЭК идет чуть дальше.
Поэтому первый практический вопрос, который я бы хотел поставить перед участниками данной конференции – как обеспечить синхронизацию МЭК-61850 и отечественной нормативной документации? Это я могу подкрепить уже в рамках услышанного словами Андрея Сергеевича, что мы отставали, начали нагонять, но при этом нам нужно выравниваться и постоянно быть на одном уровне, либо опережать по каким-то вопросам, и реальные примеры этого тоже есть. Соответственно, если посмотреть на подходы к созданию ЦПС и сравнить нашу нормативную документацию и международный стандарт, то мы увидим, что МЭК-61850 процесс проектирования в явном виде не определяет. Он определяет, какие специалисты, участвующих в проектировании, должны быть: это инженер от заказчика, составляющий ТЗ, это инженер от проектной организации (часть ПД), производитель оборудования, инженер проектной организации в части РД, инженер наладочной организации и инженер организации Заказчика, который осуществляет приемку.
И в целом на слайде 2.3. вы можете видеть, как идет весь процесс. Соответственно, процесс идет фактически по прямой, то есть из области разработки, в которой участвует Заказчик и инженер-проектировщик, уже в область реализации, когда происходит сравнение проектных решений и наложение реально существующего оборудования с последующей уже интеграцией и созданием ЦПС. При этом на разных этапах выделены моменты появления файлов электронной документации. Соответственно, первый файл – это файл SSD. Далее, начиная с третьего этапа, с конфигурации системы это файл SCD , получаемый из совмещения SSD файла и ICD файла. На четвертом этапе выделяется CID файлы, которые в индивидуальной конфигурации конкретного устройства под конкретный объект. И на этапе тестирования системы возможно появление IID файлов в случае, если что-то выделено. От пункта 5 к пункту 3 вы можете это увидеть. И в последующем обновлении SCD файла и получением нового CID файла (Слайд 2.4.).
Как бизнес-процесс определен в рамках нормативной документации в России, а конкретно в нормах проектирования ЦПС, представлено на слайде 2.5.. Соответственно, подход де-факто один и тот же. То есть здесь опыт был перенят полностью с учетом того, что порядок создания различных файлов у нас был наложен на уже каноничные этапы проектирования, начиная от общетехнических решений и заканчивая рабочей документацией, ее правками. Соответственно, файл SSD является первым файлом электронного проекта как в отечественных НТД, так и МЭК-61850.
SSD файл, как понятие для участников, это файл, в соответствии, если смотреть на МЭК-61850, это файл в формате SCL, описывающий однолинейную схему и функции подстанции, требуемые логические узлы. В соответствии с определением, приведенным в профиле «ФСК», это файл, предназначен для описания первичного оборудования подстанций и его соединения, всех функций вторичных систем, привязанных к первичному оборудованию, но не имеющих привязки к конкретному вторичному оборудованию. При необходимости данную связь можно указать. И слева на слайде 2.6. показано, как происходит разделение однолинейной схемы и перевод информации в SSD файл. Соответственно, мы выделяем различные уровни напряжения, мы выделяем элементы, отдельно выделяется элемент «трансформатор», осуществляется назначение соответствующих логических узлов, которые определяют функции данного первичного основного оборудования подстанции и формируется файл.
Соответственно, общий подход в формировании SCL файлов на примере SCD. Мы берем объект с точки зрения физики, с точки зрения систем. Происходит декомпозиция, в рамках которой отдельно выделяются функции, отдельно выделяются элементы. Применяя МЭК-61850, в нашем случае корпоративный профиль, мы можем все элементы определить. И здесь, на наш взгляд, кроется небольшая проблема в том, что МЭК-61850 достаточно абстрактен. Профиль в «ФСК» в первой его редакции, я полагаю не последняя, ввел некоторые ограничения. Но достаточно ли сегодня требований на примере SSD файла, что бы его можно было создать в разных концах России и получить одинаковый результат.
В соответствии с МЭК-61850, в составе SSD файла должны быть определены три секции: «Header», «Substation», «Data Time Template» (в случае, если мы определяем логические узлы).
Состав элементов SCL файла, который можно записывать в рамках данной секции, определяется в соответствии с SCL схемами. При этом в корпоративном профиле четко рассматривается, какая должна быть структура секции «Substation», на это идет достаточно точная отсылка. Корпоративный профиль ссылается на перечень элементов типа «Conducting Equipment» и, опять же, в корпоративном профиле нет информации о том, какие эти элементы могут быть. И уточняются аналогичные требования по составу файла. И вот «Conducting Equipment», как элемент файла SCL, в котором должны описываться элементы, определяться элементы, чтобы мы могли к ним привязать логические узлы, он, с точки зрения существующей нормативной документации, не является полным.
Соответственно, практический вопрос №3 – достаточен ли перечень основного оборудования в рамках МЭК-61850? По МЭК у нас определен 21 элемент первичного оборудования – это выключатели, разъединители, трансформаторы тока и напряжения, генераторы, все, что приведено на слайде 2.7, слева. Но, если посмотреть на однолинейные схемы, которые отражаются в проектах, мы увидим, что там могут быть предохранители, выключатели и разъединители на выкатных тележках, втычной контакт, как отдельный элемент достаточно самостоятельный или комбинированный разъединитель и заземляющий нож. Получается, что существующая опубликованная отечественная и зарубежная нормативная документация недостаточна для детального описания однолинейных схем подстанций в рамках SSD файла.
И отвечаю тогда на вопрос №2, который был поставлен ранее, то есть, применяя существующую нормативную документацию, невозможно создать SSD файл понятный всем или соответствующий действительности. Опять же, потому что нигде не определены классы банальных элементов однолинейной схемы, которые сейчас разрабатываются в проектных институтах, чтобы их переложить в SSD файл.
Соответственно, хочу показать несколько примеров решения практических вопросов, как моделировать какие-либо элементы и дать почву для размышления. В целом, общая логика моделирования заключается в следующем. Выделяется какой-либо один элемент, например выключатель, определяются его электрические точки подключения к другому оборудованию «Connectivity Node» и присваивается логический узел, который определяет функции этого выключателя. То есть выключатель, как элемент, моделируется с SCL элементом, имеющим тип «Type» и сам элемент «Conducting Equipment», функция выключателя, в свою очередь, моделируется логическим узлом XCBR. И мы считаем что при создании SSD файлов, как и в целом моделирование и создание цифрового проекта, необходимо сохранять логику, в рамках которой нужно четко разделять элементы и функции, которые выполняет этот элемент через выполнение конкретной декомпозиции нашей схемы.
Соответственно, на примере предохранителя. Мы пользуемся при разработках нормативной документации в соответствии с СТО 2008 года по типовым схемам, которые есть, на однолинейных схемах предохранитель должен быть отображен. Соответственно, из определений SSD, в соответствии с МЭК, необходимо описывать однолинейную схему четко и полностью, но предохранителя в перечне элементов «Conducting Equipment» по факту нет. Поэтому здесь можно рассмотреть 2 варианта с точки зрения моделирования. Либо мы предохранители моделируем и тогда решение этой проблемы мы предлагаем создать в будущей редакции профиля отдельный «Type» под предохранитель, либо же мы в целом через всю нормативную документацию принимаем решение, что предохранитель для отображения на однолинейной схеме просто-напросто исключается. Здесь важно оговориться о том, что в логическом узле, который моделирует функцию измерения напряжения TVTR, действительно есть объект данных, позволяющий получить информацию об отказе предохранителя. Но в тоже время в обновленной редакции МЭК-61850-7-4 отдельно появляется логический узел «Fuse» - предохранитель глава, которой вышла в 2020-м году. И это логично, если будет в SSD файле отображаться отдельный элемент, моделирующий предохранитель и к нему будет применяться логический узел «Fuse», моделирующий его функционал, аналогично, как это делается с выключателем и с другими элементами.
Точно так же и с выключателем на выкатном элементе. В рамках отображения в соответствии с СТО 2008-го года он есть. То есть и на однолинейных схемах он присутствует. При этом, чтобы его смоделировать, учитывая, что у нас втычные контакты, а это фактически видимый разрыв, то есть это у нас коммутационный аппарат без дугогасящей камеры, мы можем смоделировать выключатель на выкатном элементе как комбинацию двух разъединителей DIS1, DIS2 и непосредственно самого выключателя и присвоить ему логические узлы. Но данный подход нелогичен и вот по какой причине. Для МЭК-61850 каждый тип оборудования – это отдельный элемент, с фиксированным количеством терминалов, то есть точек подключения. Получается, что втычные контакты, которые мы прорисовываем, выключатель на выкатном элементе нужно изображать как два разъединителя и выключатель. Кроме того, возникает проблема в том, что у нас управление, если мы говорим про управляемый выкатной элемент, у нас управление происходит, один сигнал, например, на выкачивание ячейки и при этом два контакта размыкаются. То есть для реализации логики, если мы это делали через отдельные логические узлы XSWI, нам было бы необходимо дублировать тоже самое GOOSE-сообщение, которое бы управляло выкатным элементом, как таковым, и назначать его на два логических узла, отвечающих за разные втычные контакты в составе телеги. Вот.
В этом плане у нас следующее предложение. Добавить, соответственно, «Type», например, EDCB и для того, чтобы привязать функции, которые присущи именно выключателю на выкатном элементе, так как это элемент законченный и единый, добавить логический узел, например, XDOU, который бы позволял этим элементом управлять и который бы описывал его функции. И тоже один из интересных элементов и вопрос как моделировать его правильно, поскольку, чем жестче мы закрепим нормы по моделированию, тем точнее и проще можно будет реализовывать программное обеспечение.
На примере трансформатора что мы можем увидеть? В рамках требований СТО, трансформатор определяется как один элемент, это рисунок слева на слайде 2.8. вы можете увидеть. На практике проектная организация разрисовывает керны трансформатора или трехфазные группы с целью показать, что к чему подключается. Соответственно, у нас физический элемент трансформатор тока – это один элемент, в рамках одного элемента есть несколько кернов трехфазной группы обмоток. Соответственно, в SSD описание однолинейной схемы по трансформатору тока отображается в основном в трехфазном исполнении. Также должно быть и в SSD файле. Поэтому и по факту можно 4-мя вариантами попытаться описать данный элемент в рамках SSD файла.
Вариант 1-й – это, используя «Type» «ConductingEquipment» CTR, мы можем к нему присвоить теперь столько логических узлов, сколько у нас обмоток измерения по факту. То есть, учитывая пофазность, учитывая общее их количество, но при таком представлении непонятно, сколько у нас по факту, если мы переводим обратно в графическую аннотацию, сколько у нас действительных кернов в рамках одного трансформатора, то есть просто перечень обмоток.
2-й вариант описания – разбить трансформатор на трехфазные группы измеренческих обмоток и каждую обмотку представлять, как отдельный трансформатор в составе SSD файла. При этом, чтобы выделить пофазно каждую обмотку, использовать элемент «SubEquipment» и присваивать один логический узел.
3-й вариант – разбить трансформатор на три однофазных трансформатора, в рамках которых можно использовать логические узлы. Соответственно, на количество логических узлов в рамках одной фазы у нас будет соответствовать количеству выводов, количеству кернов по этой фазе.
Вариант №4 – это в рамках одного элемента «CurrentTransformer» использовать «SubEquipment» для того, чтобы разделить обмотки на трехфазные группы и, соответственно использовать логические узлы.
Это те примеры, которые на наш взгляд нужно прорабатывать. И поскольку SSD файл является первым файлом, который нужно формировать и пока что он в основном может быть сформирован руками, про программные продукты мы поговорим чуть попозже, нужно с самого начала подходить правильно к подходу что мы описываем в файлах электронной конфигурации, а что мы не описываем. Поэтому можно сделать по факту три вывода, то, что:
- При разработке цифровых проектов как для SSD файла, так и для других SCL файлов, необходимо соблюдать четкую логику при декомпозиции объекта/системы/функции и описания полученных элементов в рамках SCL;
- Необходимо при разработке НТД уделять особое внимание белым пятнам, которые являются допущениями в МЭК-61850;
- Ответ на практический вопрос №1 – как соблюсти синхронность стандартов международного и нашей локализации в виде профиля? Это обеспечить непосредственно своевременную доработку обновления данных по стандарту и создать в рамках российского профиля МЭК-61850 аналог tissue. То есть это фактически сайт, в рамках которого можно: а) писать замечания всем, кто занимается МЭК-61850 и участвует в разработки или применяет его, б) получать обратную связь по тому, какие из приведенных замечаний по факту являются устраненными и действительно это были опять же очередные нашлись белые пятна, которые нужно закрывать и там в следующем переиздании стандарта они будут закрыты. Либо же получать какое-то четкое объяснение, почему так делать не надо.
Коллеги, на этом все по моей презентации. Передаю слово Александру Волошину для доклада, посвященного вопросу применения открытых онтологий для проектирования и эксплуатации цифровых подстанций.
Опять же много разговоров было посвящено тому, что CIM сначала надо доделать, а уже потом его применять. На самом деле разработка CIM это бесконечная история, которая идет уже с 1996-го года, а нам нужны такие технологии, которые позволяют применять CIM уже сейчас, делать для него несколько профилей и уметь между этими профилями переключаться. Было много про это сказано, но не приходится надеяться на то, что мы в ближайшее время получим какой-то идеальный CIM, поэтому нужны информационные модели, но нужно уметь с ними работать в условиях, когда они меняются. Это вызов, на который мы должны ответить.
На мой взгляд, парадигма проектирования уже поменялась, и когда говорится про создание SCD, SSD файлов, то все равно подразумевается, что здесь основную творческую функцию будет выполнять человек, а все программные средства, которые мы сейчас называем САПР – это, по сути, электронный кульман, в котором у нас есть заранее заготовленные шаблоны. Из библиотеки мы их достаем и соединяем линиями и получая, таким образом, какое-то решение. На мой взгляд, это не цифровое проектирование. И система автоматизированного проектирования – это уже не просто электронный чертежный инструмент, пускай там и с автоматизацией каких-то рутинных операций, а это уже, по сути, интеллектуальный ассистент проектировщика. То есть проектировщик должен задавать цели, метрики и ограничения, а машина САПР должна находить решения. То есть это интеллектуальный ассистент. В этом смысле САПР должен предметно знать область, требования НТД и лучшие практики, а для этого как раз и нужны онтологии, базы знаний и машины логического вывода, и другие методы искусственного интеллекта тоже. То есть мы должны уметь загружать в САПР наши требования, правила, которые мы хотим, чтобы он выполнял, а затем под каждую новую главную схему система должна синтезировать нужное нам решение.
На слайде 3.1. мы показываем то, что у нас уже сейчас работает. В прошлом году мы выполнили научно-исследовательскую работу, когда на входе, имея однолинейную схему подстанции, компьютерная программа, в которую загружена онтология норм и требований, правила построения РЗА на ЦПС, синтезировала решения. То есть по каждому элементу, представленному в SSD файле, формируются определенные универсальные запросы и база знаний, методом логического вывода генерирует ответы, которые позволяют в автоматическом режиме отобразить на схеме нужный состав функций. При этом система не просто ищет какие-то элементы активов как, например, трансформаторы, которые в явном виде задаются, но и ошиновки, и шины. То есть она логическими методами вывода новых знаний выделяет эти элементы на схеме и присваивает им защиты в соответствии с требованиями.
И более того (Слайд 3.2.), получив такую информационную модель связей, источников сигналов, функций и вывода управляющих воздействий, фактически мы можем автоматически синтезировать схему логики релейной защиты и структурно-функциональной схемы. То есть мы загружаем главную схему подстанции и получаем как структурную схему ПТК, таки схему логики. Причем, если мы используем наши программные компоненты, то мы можем сделать полностью готовый исполняемый файл для загрузки в контроллер. И это не фантастика. Это уже сделано и запатентовано.
Теперь про типовые шкафы. По этому вопросу я часто спорю с коллегами из «ФСК». На мой взгляд, измерять цифровую релейную защиту шкафами – это все равно, что измерять программное обеспечение килограммами. Сейчас про типовые решения на самом деле я не могу подтвердить, что это какой-то тренд. Наоборот, идет серьезная «кастомизация», Generetive Design – концепция цифровых двойников, когда мы под каждую конкретную задачу с максимальной эффективностью выбираем решения, а затем роботы, не знаю аппаратные или программные, «кастомно» делают. И на самом деле вот это и является трендом. На мой взгляд, типовые шкафы – это, на самом деле, прошлый век. Надо уже смотреть в будущее.
Мы много говорили про требования надежности и вообще, как проектировать. Новая парадигма позволяет сразу задать желаемые цели и задать им метрики, она как раз позволяет решить этот вопрос, то есть компьютер сам подберет нужное решение под нужные критерии. Сейчас при проектировании очень много опций, очень большая гибкость в цифровых системах. Становится сложно найти не только оптимальное решение по критериям затрат и надежности, а становится сложно в принципе собрать это решение, чтобы оно работало. Поэтому нужны такие методы проектирования, которые сразу же будут нести в себе измеримый результат, а именно проектную оценку надежности и сразу же оценку затрат на стоимость и владение на всем жизненном цикле.
В нашем САПРе это тоже реализовано (Слайд 3.3.). Мы можем, задавая требуемый уровень надежности, вычислять, какая при этом будет стоимость владения комплексом РЗА, а самое главное показать насколько при этом снизится ущерб. Дело в том, что релейная защита, какая бы надежная и совершенная она ни была, ущербы до нуля не снижает. Очень часто избыточные требования по защите на уровне энергосистемы приводят к тому, что затраты на повышение надежности и, соответственно, стоимости защиты, не обоснованы. Они приведут к тому, что эффекты от снижения ущербов будут гораздо меньше, чем стоимость этих решений. И без такой рулетки, которая позволяет это измерить, проектировать новые технологии нельзя. Иначе у нас достоверность и обоснованность решений не гарантируется.
В принципе, если говорить о цифровых решениях в традиционном понимании (Слайд 3.4.), как РЗА ЦПС, они не могут обеспечить экономической эффективности. То есть мы получим ту же самую функцию отключения поврежденного оборудования только на основе стандарта МЭК-61850 и так далее. То есть для того, чтобы цифровые решения давали эффект, они должны не только снижать ущербы при коротких замыканиях, они должны генерировать ценность в процессе своей работы, когда такого короткого замыкания нет и ущербов нет. Это тоже вызов и над этим надо тоже работать.
Если рассматривать решения по цифровизации на уровне какого-то филиала в целом (Слайд 3.5.), то ситуация становится еще хуже, а если говорить про 110-220 кВ, где у нас и так резервирование, то в капитальных и операционных затратах потенциал в снижении небольшой. И сам этот вклад в цифровизацию, если мы рассматриваем только функционал защиты и автоматики, он в принципе эффекта дать не может. В масштабе это только усугубляет ситуацию.
Следует сказать, что применение онтологий, правил построения систем возможно не только для синтеза решений по защитам по ЦПС (Слайд 3.6.). Мы в этом году закончили НИОКР, которые позволяют синтезировать схему микроэнергосистемы для распредсети. При этом у нас есть три крупных параметра оптимизации – это вложения в резервированные ЛЭП, это распределение по этой сети возобновляемых источников энергии и накопители электроэнергии, это повышение интеллектуальности системы управления и защиты. Внутри этих трех больших направлений оптимизации мы можем синтезировать решения и сразу же по ним считать совокупную стоимость владения и надежность этой системы с учетом показателей надежности защиты. И таким образом, оптимизировать эти решения не только на уровне технологической сети на подстанции, но и в целом микроэнергосистемы целиком.
Эти технологии позволяют проанализировать то, к каким последствиям приведут в отрасли те или иные НПА и НТД, принимаемые на уровне Минэнерго. И эти же технологии онтологического моделирования позволяют смоделировать не только РЗА ЦПС, но и весь ее жизненный цикл и даже оценить бизнес-показатели.
Теперь самое интересное (Слайд 3.7.). Мы много говорим про то, что продуктом, сегментом надежных гибких сетей в НТИ является бизнес-модель. Так вот разработанные нами технологии позволяют на основе известных нормативных и технологических ограничений сформировать бизнес-модель под заданные условия. Что особенно важно для выхода на новые рынки, где нормативная база может сильно отличаться от нашей. И проектирование этой бизнес-модели тоже может быть сделано с применением онтологии познания методов логического вывода, мультиагентного моделирования взаимодействия субъектов и, естественно, математического моделирования самой технологической составляющей.
Когда мы говорим про новую парадигму проектирования (Слайд 3.8.), нужно обязательно учитывать то, что она меняет и принципы взаимодействия людей, субъектов в этом процессе. Мы формализовали текущий бизнес-процесс по проектированию, жизненный цикл всей проектной документации, начиная со стадии «ОТР» и заканчивая выводом из эксплуатации. На самом деле, когда у нас появляются онтологические модели, позволяющие с помощью методов логического вывода научить машину рассуждать и синтезировать нужные решения, то можно решать и обратную задачу. Например, может быть интеллектуальный ассистент, который будет автоматически проверять правильность проектных решений. У нас такой проект НИОКР сейчас реализуется, в следующем году мы будем показывать результаты, но смысл в том, что этот файл электронной документации должен быть снабжен значимой электронно-цифровой подписью и вообще взаимодействие субъектов в этой системе тоже может быть автоматизировано.
По поводу применения онтологии на стадии эксплуатации, то сейчас реализуются такие проекты, когда реальная работа комплексов РЗА на подстанциях сравнивается с некоторой работой модельных комплексов РЗА. И этот путь я считаю экстенсивным, потому что он требует двойного или тройного инжиниринга, требует постоянно настраивать модель релейной защиты, чтобы она соответствовала тому, что находится в эксплуатации. Это очень большой дополнительный объем трудозатрат. Применение онтологии позволяет сформировать этот синтез, провести синтез эталонных сигналов, с которыми можно сравнивать реальные сигналы на основе методов логического вывода, на основе требований к срабатыванию. Когда мы знаем, где произошло короткое замыкание, то человек, опираясь на требования, может сказать какой правильный ожидаемый должен быть порядок срабатывания защит, исходя из предъявляемых требований. Именно это и позволяет нам сделать онтологическую модель и методы логического вывода. При этом не требуются бешеные трудозатраты по поддержанию модельной релейной защиты, такие трудозатраты нести не нужно, потому что гораздо меньше этих трудозатрат требуется для создания этих моделей на основе, например, языка описания OWL. Если мы внедряем какие-то новые решения по проектированию, то единственным, наверное, критерием эффективности должно быть сокращение трудозатрат. Если мы не можем гарантировать, что какое-либо из решений, которые мы предлагаем, эти трудозатраты сокращают, значит это решение недостаточно продумано и его внедрять широкомасштабно еще нельзя. Поэтому вот все, что мы сейчас говорим про МЭК-61850 сейчас, к сожалению, приводит только к увеличению этих трудозатрат. Да, применять это нужно, потенциал в этом большой, но сама технология применения этих стандартов CIM и МЭК-61850 должна всегда обеспечивать сокращение трудозатрат, и повышение качества, и эффективности работы проектировщиков, и наладчиков, и эксплуатации. На этом у меня все. Спасибо!
Модератор: Александр Александрович, спасибо. Один из вопросов, который был задан, звучит следующим образом: «В итоге ваших суждениях о будущем, остается ли место человеку?» Волошин Александр Александрович: Да, конечно. Еще раз повторюсь, вся эта интеллектуализация — это помощник для человека. Дело в том, что цели и желания являются прерогативой человека. Это как станок с ЧПУ. Мы можем сами на нём эти отливки гипсовые делать, а можем заложить в программу, и он повторит ее 1000 раз, поэтому мы здесь не переживаем и роль человека понятна. В принципе и в любых других отраслях будет тоже самое. То есть хирурги будут скоро также ставить задачу роботам-хирургам. Например, операции на глаз, когда делаются или еще что-то. То есть это нормальный, хороший, правильный путь развития. Модератор: Появились вопросы, которые пришли к нам в чате. Вопрос первый: « Как строится онтологическая база?» Волошин Александр Александрович: Сейчас это еще некоторое искусство. То есть человек, который знает эти правила или нормы технологического проектирования определенным образом проводит так называемый инжиниринг знаний и записывает это в определенном виде, понятный машине. Это тоже вызов будущего. Сейчас у нас стартовало два НИОКР – это автоматическое построение этих онтологий из анализов текстов НТД и автоматическое построение онтологий и правил проектирования, исходя из анализа проектных схем. Но пока переложение знаний, норм и требований в специальный язык происходит вручную – это то, что называется инжинирингом знаний. Модератор: Хорошо. А коллег, судя по вопросам в чате, зацепил вопрос о типизации шкафов. Вопрос звучит следующим образом: «Что конкретно в типовых шкафах противоречит целям развития РЗА?» Волошин Александр Александрович: Я не могу сказать, что там что-то противоречит целям развития РЗА. Я могу сказать, что разработка типовых шкафов нацелена на как бы правильный результат, но только в настоящий момент это уже не является самым эффективным способом достижения этого результата, так как есть гораздо более эффективные способы. То есть инструмент достижения этого результата, как типизация, он не самый эффективный. Модератор: И еще вопрос. Что будет, если система синтезирует решение с ошибкой? Волошин Александр Александрович: Этот вопрос очень правильный. Недавно я читал цикл лекций по применению искусственного интеллекта в электроэнергетике. Любое решение, которое синтезирует искусственный интеллект для электроэнергетики должно быть проверено, должно быть симулировано и здесь мы должны иметь гарантию. Собственно говоря, здесь человек у нас остается. То есть, кто будет отвечать за ошибку искусственного интеллекта в электроэнергетике – это серьезная дилемма и над ней надо работать. Это из разряда вопроса, кто будет отвечать за ошибку, например, искусственного интеллекта при управлении беспилотным автомобилем. То есть это общая наша задача, которая стоит во многих отраслях. Модератор: И, наверное, последний вопрос: «Вы говорили о возможности синтезирования схем релейной защиты на основании нормативной базы и упомянули ее по ЦПС. А какую нормативную базу в итоге вы заложили и используете? Это были международные стандарты или применяли отечественную нормативную документацию в этом направлении?». Волошин Александр Александрович: Мы использовали отечественную нормативную базу. Единственное только не могу сейчас гарантировать, что мы ввели все последние требования. Над этим надо работать. И вот в чем смысл открытых онтологий? Дело в том, что на самом деле эти все нормативные базы, НПА и НТД целесообразно сразу выпускать в онтологическом виде, чтобы не было вопросов в интерпретации этих требований. Потому что на самом деле онтология позволяет вычислить все противоречия, а это, к сожалению, достаточно часто встречается в наших нормативных документах, когда один документ противоречит другому. В будущем, особенно при таком создании инфраструктуры, создании онтологий, это для любой отрасли может быть справедливо. На самом деле подход, который мы изобрели, сейчас начинаем реализовывать в двух смежных отраслях. Он универсальный. Можем синтезировать, по сути, любую вещь. Если у нас есть специальные правила онтологии, системе абсолютно без разницы, что синтезировать. Модератор: Уважаемые участники нашей конференции, на этом конференц-часть подошла к концу. Предлагаю в 15:55 вернуться к цифровой подстанции, к МЭК-61850, к текущим проблемам, которые связаны с работой по проектированию в данном направлении, чему наш круглый стол и посвящен. И вместе со всеми участниками выявить наиболее критические точки. Спасибо!