Модератор. Чайкин Вячеслав Сергеевич. Начальник Управления цифровых технологий и IT-решений АО «ФИЦ»: Уважаемые, коллеги! Возвращаемся к нашей повестке дня. Вопросы изменения парадигмы проектирования цифровых подстанций. У меня подготовлены вопросы для каждого из участников, кого я обозначил и подготовлен общий вопрос. Сначала мы рассмотрим частные вопросы, и если в рамках ответа участника у вас появятся свои вопросы и комментарии, то прошу их высказывать.

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

Аношин Олег Анатольевич. Директор по направлению цифровой подстанции ЭТЗ «Вектор»: Давайте сразу оговоримся, что наше предприятие выпускает и реализует проекты по ЦПС не только для «Россетей», но и для добывающей промышленности, нефтеперерабатывающих и нефтедобывающих холдингов, поэтому мы имеем опыт решений по ЦПС во всех этих отраслях. И надо сказать, что подход в их реализации на предприятиях «Россетей» довольно существенно отличается от подхода на промышленных предприятиях.

Первое, с чем мы столкнулись при реализации проектов ЦПС – это крайне низкий уровень квалификации проектных организаций. То ли нам не повезло и поэтому проектные организации, которые занимались проектированием данных, объектов не обладали нужной квалификацией, то ли это общие тенденции, которые имеют место на российском рынке. В 90% случаев проектная организация при реализации объекта ЦПС, как правило, ставила перед нами задачу разработки не только заводских схем вторичных цепей, но и разработки SSD и SCD файлов. Что, собственно, мы и делали при реализации практически всех проектов. Кроме этого, зачастую при реализации проектов ЦПС для промышленных предприятий, наш уровень знаний был более высоким, чем уровень знаний заказчика на промышленном предприятии и, поэтому мы в какой-то степени диктовали техническую политику при реализации данных объектов. Это существенно упрощало проектирование подстанций, поскольку мы применяли критерии, которые существенно снижали объем проектирования и демонстрировали те положительные возможности ЦПС, которые у нас сегодня есть.

Что касается реализации проектов или участие в проектах для «Россетей», то здесь оказалось все гораздо сложнее, потому что существенным требование являлось наличие резервирования цифровых решений, особенно для GOOSE-сообщений, сухими контактами. И это, казалось бы, очень маленькое требование в техническом задании на проектирование приводило к тому, что мы сначала должны были создать аналоговую подстанцию, а на нее наложить цифровые решения. Это существенно усложняло разработку заводской технической документации для проектных институтов. Могу сказать, что мы отслеживаем, как это внедряется на объектах, и знаем, что все те объекты, которые прошли через наше предприятие, в которых данное требование существовало, параллельное резервирование сухими контактами, в цифре потом так ничего и не запустились. Они так, собственно, и работали по сухим контактам или, грубо говоря, вместо второй-третьей архитектуры ЦПС на этих объектах реально работала только 1-я архитектура.

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

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

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

Модератор. Чайкин Вячеслав Сергеевич: Вопрос: «А какими инструментами вы пользовались при разработке цифровых проектов?»

Аношин Олег Анатольевич: С рядом компаний у нас давно налажено хорошее сотрудничество. И в части проектирования цифровых решений мы работаем на аутсорсинге. Хотя подумываем о том, что этот опыт можно набирать на заводе, но это вопрос, который еще требует обсуждения, потому что объем цифровых решений в среднем напряжении, а все-таки мы среднее напряжение, пока велик, и имеющийся опыт аутсорсинга крайне положительный. Он нас вполне устраивает, потому что компания, которая помогает нам исполнять типовые цифровые решения, уже потом организовывает нам наладку или заливку CID файлов в терминалы релейной защиты и контроллеры. Таким образом, все свои реализованные ЦПС мы отдаем, что называется Plug&Play, поскольку заказчики ее принимают у нас прямо на заводе вплоть до прогрузки уставок релейной защиты. То есть мы показываем работающую ЦПС, работающую распределенную релейную защиту и противоаварийную автоматику, показываем работающую систему АСУТП. И только после этого отгружаем заказчику нашу подстанцию. Это то преимущество, которое мы не могли бы иметь, работая с аналоговыми подстанциями.

Модератор. Чайкин Вячеслав Сергеевич: Вами было сказано, что в некотором виде вы диктовали заводам техническую политику. Как ваши заказчики, получив от вас знания о цифровой подстанции, осуществляли ее приемку?

Аношин Олег Анатольевич: Практически во всех проектах, в которых мы участвовали, в процесс проектирования, изготовления и наладки подстанции обязательно входил процесс подготовки персонала. Представители заказчика выезжали к нам на предприятие, примерно за месяц до ее приемки, мы обеспечивали им обучение, то есть введение в основные положения МЭК-61850 и, соответственно, рассказывали о тех конкретных цифровых технических решениях, которые мы применили для их объекта. Затем они, вооружившись этими знаниями, через месяц приезжали к нам, и уже сами смотрели, как бегают GOOSE-сообщения, как проходят буферизированные, не буферизированные отчеты и отражаются в системах АСУТП, как подключаются дополнительные многочисленные системы: видеоконтроля, температурного контроля, контроля изоляции и т.д. и т.п. В том числе искусственно создавали различные секционные аварийные ситуации, чтобы посмотреть, как правильно отработает та или иная система в целом. Для промышленных предприятий это крайне важный момент, поскольку эта технология может быть опасна для жизни человека. И там несколько другие требования к этим вещам. То есть мы моделировали различные варианты отказа тех или иных элементов ЦПС для того, чтобы посмотреть, как отрабатывает уже собранная и изготовленная подстанция. Это, на мой взгляд, очень важно не только для промышленных предприятий, но и в том числе для «Россетей». Но это отдельная тема, поскольку с одной стороны, технические требования, в том числе «Россетей», требуют применения этих систем, но сегодня практически нет ни одного производителя, который бы говорил о том, что да, система температурного контроля у меня поддерживает МЭК-61850 и она легко интегрируется.

Модератор. Чайкин Вячеслав Сергеевич: Вопрос, который вам адресует участник нашей конференции: «Сколько процентов электронного проекта реально использовалось для настройки цифровой РЗА, цифровых систем, а какую часть приходилось настраивать вручную через инструменты производителей?».

Аношин Олег Анатольевич: Как я говорил, электронный проект делался по аутсорсингу и, собственно, наладка цифровой части нашего технического решения делалась также по аутсорсингу, но, кстати, здесь есть очень интересный момент. Учитывая технологии ЦПС, эта наладка зачастую происходила удаленно без приезда специалистов к нам на предприятие, что тоже показывает довольно существенные преимущества, связанные с применением цифровых технологий. Я могу проанализировать только временной фактор. Если мы говорим о времени, скажем, загрузки цифрового проекта на сам объект, то это занимало примерно около недели на территории нашей подстанции. Потом примерно, около недели уходило на то, чтобы выявить ошибки проекта как электронного, так и ошибки схемных решений. И скорректировать электронный проект, соответственно, скорректировать CID файл. Но все-таки мы старались полностью использовать методологию МЭК-61850 и, если находили какие-то неисправности в электронном проекте, то сначала правился электронный проект, а потом переконфигурировались терминалы релейной защиты. Вручную же мы в них ничего не корректировали. Это было связано с тем, что во всех проектах мы всегда применяем как систему мониторинга цифровых коммуникаций, так и систему мониторинга соответствия цифрового проекта с тем, что реально сконфигурировано в устройствах.

Модератор. Чайкин Вячеслав Сергеевич: Олег Анатольевич, большое спасибо! Вы сказали, что с проектировщиками вам не повезло, а Николай Юрьевич Зайцев как раз представитель династии проектировщиков. Николай, вряд ли обвинения касались именно вас, но вопрос к вам. Поделитесь, пожалуйста, опытом, что изменилось при проектировании цифровых подстанций? Как изменились ваши подходы в проектировании и с какими трудностями вы столкнулись?

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

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

И те же самые согласования с РДУ и с заказчиком, будь то «МРСК» или «ФСК», все равно в каком-то виде требуют выполнения схем. Соответственно, наряду с разработкой SCD файл, дополнительно разрабатывается и сама документация. Когда мы только начинали работать по теме ЦПС, а это была подстанция на 110 / 20 кВ «Медведевская», тогда я работал в НПП «ЭКРА», то на тот момент вообще не было нормативных документов, соответственно, базы. Сейчас в этом направлении уже имеется много наработок и проектировщикам в этом плане значительно легче. Я вспоминаю 2017-е, 2018-е года, когда мы только вводили определенные обозначения и те же самые сигналы нумеровали. Тут коллеги правильно говорили, что сигналы должны быть в принципе стандартизированы, чтобы у всех было их четкое понимание. Сейчас пока это все только на начальном этапе.

Модератор. Чайкин Вячеслав Сергеевич: Требуют ли сейчас заказчики непосредственно SCL файлы, то есть SSD, SCD, как это положено по МЭК-61850, на этапе «ПД», на этапе «РД», так как это сейчас требует вышедший свежий стандарт «ФСК ЕЭС». Если да, получается ли их выдавать вовремя, и какие инструменты вы используете для того, чтобы данные файлы создать?

Зайцев Николай Юрьевич: Всегда в тех проектах, которые я проектировал, мы применяли оборудование НПП «ЭКРА» и в этом году у нее появился софт, который позволяет эти файлы конфигурировать непосредственно самому проектировщику, а не заводу. Что касается заказчика, то у него не всегда есть этот софт, но следуя протоколу МЭК-61850, этот файл запрашивают. Правда было и так, что мы его предоставляли, а заказчик проверить его конкретно не мог. Тут либо «Теквел» подключался, либо сам завод-производитель оборудования РЗА. Именно каких-то внятных и конкретных замечаний от заказчика по SCD файлов на своей практике не было, но были вопросы каким программным продуктом и как этот файл можно посмотреть.

Модератор. Чайкин Вячеслав Сергеевич: Был ли у вас мультивендорный проект, и какой опыт работы в рамках частного САПР, который производит компания-производитель оборудования релейной защиты.

Зайцев Николай Юрьевич: Был конкретный опыт интеграции, допустим, релейной защиты одного производителя и АСУТП другого производителя, но там мы тоже ограничились тем, что разрабатывали файлы в части оборудования РЗА и передавали файлы SCD производителю АСУТП. И уже потом на объекте они, используя эти файлы, дорабатывали при наладке какие-то моменты, но именно такого опыта, чтобы с программным обеспечением одного производителя спроектировать другой, то такого пока еще не было.

Модератор. Чайкин Вячеслав Сергеевич: Вопрос от участников конференции: «Поделитесь впечатлениями от используемого вами САПР по МЭК-61850 и что в нем, на ваш взгляд не хватало, а сейчас появилось при разработке электронного проекта?».

Зайцев Николай Юрьевич: В принципе раскритиковать и похвалить сложно, потому что не с чем сравнивать. Работали с тем, что есть, но принципе, довольны. Он нас устраивает. Сам завод всегда идет навстречу. Если есть какие-то непонятные моменты, то можно обратиться и спросить.

Модератор. Чайкин Вячеслав Сергеевич: Большое вам спасибо! Тогда хотелось бы перейти к производителям оборудования РЗА, соответствующие МЭК-61850. Слово Алексею Дымшакову. Алексей, нам известно, что ваша организация производит достаточно большую номенклатуру оборудования для ЦПС. Учитывая появляющиеся нормативные документы, опять же файлы ICD вашего оборудования, которые вы предоставляете проектным организациям, то объем их приватных полей вы уменьшаете в этих файлах и уменьшается ли количество событий, когда использование ваших файлов, с использованием файлов других производителей, не позволяет создать SCD файл?

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

Что касается проектирования, то тут есть интересный момент. Когда только начались ЦПС, многие проектировщики не знали куда бежать, и они просто бежали к производителю, потому что вряд ли кто-то лучше спроектирует, чем производитель на своем оборудовании, который знает все нюансы. И мы массово делали и проекты и SCL файлы, и SCD с разными производителями. Мы для этого купили софт, сами писать мы его не стали, потому что понимали, что в «НТЦ ФСК» ведется большая работа по созданию глобального САПР. Какой тогда смысл нам делать его самим? У нас есть софт канадской компании, называется «Grid Software». Купили полностью весь комплекс, включая тестовый комплекс, обучили ему наших проектировщиков, и сейчас у нас проблем в создании этих файлов нет.

По поводу реализации профиля. Да, производителям надо время, чтобы его реализовать и протестировать у себя самое главное. Мы это пробовали и хотели бы создать у себя полностью объект по профилю и протестировать все связи уже по МЭИ, по штормовым испытаниям, по другим нашим испытаниям, чтобы проверить, что это все нормально работает, что там нет каких-то проблем с той же синхронизацией, про которую все говорят. И она реально для 9.2 проблема, если она там неправильно продумана.

Модератор. Чайкин Вячеслав Сергеевич: Вы упомянули, что закупили зарубежный САПР. Видите ли вы риск в том, что зарубежный разработчик САПР просто не поддержит те расширения или те типовые, которые будут? Или вы планируете в момент, когда появится САПР «ФСК», вы просто откажетесь от существующего продукта, которым сейчас пользуетесь?

Дымшаков Алексей Викторович: Так и есть. Мы просто откажемся. На самом деле нет никаких проблем создать в нем профиль НТЦ, а точнее профиль, который в «ФСК» сейчас сделали. То есть мы в нем его и реализовали. Там все прекрасно настраивается. Можно по профилю создать модели, а можно и не по профилю. На то он и САПР, чтобы в нем можно было делать различные вещи.

Модератор. Чайкин Вячеслав Сергеевич: В продолжение этой темы хотел бы задать вопрос Дмитрию Борисовичу Антонову – начальнику лаборатории релейной защиты АО «РАДИУС Автоматика». Дмитрий Борисович, вы разрабатываете САПР и даже всем желающим предоставили его на бета-тестирование. Какие отзывы вы получили от проектировщиков или может быть от производителей оборудования?

Антонов Дмитрий Борисович. Начальник лаборатории релейной защиты и автоматизации компании АО «РАДИУС Автоматика»: На самом деле с САПР получилось интересно. Когда мы к нему приступили, то в этот период началось активное внедрение ЦПС. Изначально же мы ставили себе цель не просто сделать системный конфигуратор по 6-й главе, а получить для себя инструмент, с помощью которого мы ЦПС сможем тоже налаживать и настраивать. Когда же появилась первая версия, то мы ее передавали на тестирование и отзывы были очень разные. Практика показала, что на обучающих семинарах большинство участников даже не понимали, для чего нужен САПР и путали его с проектирующим как AutoCAD. Приходилось объяснять, что теперь у нас две независимые системы, которые выполняют разные части проекта. И судя по последним отзывам, теперь уже действительно начинают делать реальные проекты, когда файлы создаются не для галочки, чтобы отдать заказчику, а заказчик, не используя их, просто принимает работу. Сейчас появляются объекты, где САПР действительно используется уже для дела, то есть получаются на выходе файлы, которые можно загружать в терминалы.

В частности, у нас был объект, в котором мы выступали в качестве проектировщиков именно электронной части, в том числе, загружая результаты в свои и в чужие терминалы, соответственно.

Модератор. Чайкин Вячеслав Сергеевич: То есть вы не столкнулись с какими-то локальными проблемами совместимости? То есть используя разные ICD файлы на входе, вы все равно получали корректные SCD на выходе, которые потом еще обратно формировались в CID?

Антонов Дмитрий Борисович: На самом деле затруднения есть до сих пор. Даже в свежих проектах. Как правило, загрузка ICD или CID файла от производителя не доставляет проблем. Они проходят валидацию, в том числе у нас в САПР, они подгружаются в систему и она их нормально воспринимает. При настройке, правило, вопросов тоже нет. Но на выходе мы столкнулись с ситуацией, что мало кто из производителей поддерживает цикл проектирования по 6-й главе. То есть у нас на выходе появляется файл SCD, но загрузить его фактически некуда. И на вопрос к производителю: «А как это настроить?» Они говорят: «Ну вот берете наш инструмент и ручками настраиваете CID и все остальное». По нашему опыту примерно, максимум 50% оборудования, удавалось настроить с помощью CID файлов, которые мы выгружали, а все остальное донастраивать приходилось руками. Поэтому сложилось впечатление, что сейчас проходим некий переходный режим, так как производители на этапе освоения и реализации этих технологий.

Модератор. Чайкин Вячеслав Сергеевич: Сейчас вопрос вам и параллельно Алексею Дымшакову. У вас, как у производителя, была ли проблема в том, что SCD файл был кем-то собран, и вы не могли на вашем оборудовании его «переварить».

Антонов Дмитрий Борисович: Да. Были вопросы и замечания к нашему оборудованию. Естественно, мы в своих решениях неидеальны, но мы всегда идем навстречу, и если это были наши ошибки, то мы, соответственно, их исправляем.

Дымшаков Алексей Викторович: На официальном этапе были. С кем-то из производителей и сейчас остались. Нюансы, конечно, есть всегда. Если бы сейчас здесь был бы реальный наладчик, то он много интересного рассказал бы о том, как это все работает. А перед сдачей он сидит и с некоторыми устройствами все это делает вручную.

Модератор. Чайкин Вячеслав Сергеевич: Как раз вопрос о ручной работе. Дмитрий Антонов сказал, что половину прогружали, а половину руками. Вы именно конфигурации забивали в терминал, учитывая проект, или корректировали SCD файл в проприетарных софтах для параметрирования в терминалах, чтобы из него создать CID файл?

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

Модератор. Чайкин Вячеслав Сергеевич: Дмитрий, а у вас такая функция работает?

Антонов Дмитрий Борисович: Да, работает так как поддерживается данный сервис.

Модератор. Чайкин Вячеслав Сергеевич: Алексей сказал, что те проекты, в которых было необходимо сконфигурировать терминал, SCD файл фактически не прокладывался. Была просто ручная настройка или доработка именно CID файла?

Антонов Дмитрий Борисович: По нашему опыту это была ручная настройка через проприетарный инструмент производителя.

Модератор. Чайкин Вячеслав Сергеевич: Большое спасибо. У Аношина Алексея Олеговича имеется богатый опыт в наладке терминалов разных производителей. Алексей Олегович, как мне известно, вы данными проектами занимались?

Аношин Олег Анатольевич. Директор по направлению цифровой подстанции ЭТЗ «Вектор»: Я только могу подтвердить опыт, о котором Алексей и Дмитрий говорили. Существуют две категории проектов. Категория проектов на одном вендоре, когда вся конфигурация создается в конфигураторе вендора, и они называются «System Configuration Tool», но по факту преимущественно конфигурирует один терминал, то есть большую часть функционала ICD и, соответственно, там вообще никаких проблем нет.

Что касается бизнес-процесса, когда проектировщик делает SCD файл, а дальше наладчик должен этот SCD файл импортировать в терминал на объекте, то это идеальная картина, которая не везде работает. И здесь бывают разные подходы. В конечном счете, задача на текущий момент состоит в том, чтобы выстроить процесс так, чтобы на выходе был итоговый SCD файл с соответствующей конфигурации. Средства в данном случае уже вторичны. И сейчас, наверное, больше проблем на стороне производителей с точки зрения того, чтобы втянуть в себя конфигурацию SCD файл. У кого-то это реализовано полностью, у кого-то еще не до конца. Но, в конечном счете, это все делается на объектах. Если есть человек, который понимает, что это надо сделать, и он обладает должной настойчивостью, то это делается.

Модератор. Чайкин Вячеслав Сергеевич: С точки зрения текущей информации в составе SCD файла, видите ли вы необходимость введения дополнительного объема каких-либо данных или файл достаточен для того, чтобы полностью все спараметрировать без каких-то других воздействий?

Аношин Олег Анатольевич: Я не до конца понял вопрос. Мы сейчас говорим об SCD файле? О нем мы говорим, грубо говоря, как о замене раздела «Кабельный журнал» и «Электрическая принципиальная схема» в «рабочке». Когда же мы говорим о процессе наладки, то об SCD файле мы говорим, грубо говоря, как о параметрировании выходов логических сигналов на клеммы терминала. В этом смысле не надо переоценивать роль и важность SCD файла в том, что он все проблемы решает. Конечно, этого нет. Уставки сейчас у большинства терминалов задаются отдельно, программируемая логика, если она есть, она тоже задается отдельно. Надо ли это все объединить? Конечно, надо. Это мое мнение, но опять же, многие нас знают, как цифровизаторов, которые уже десять лет цифровизируют, и мы понимаем, что это процесс небыстрый. Сейчас, к счастью, большая часть заказчиков начинает осознавать, что им это необходимо. Они начинают это смотреть, анализировать, часто с нашей помощью. Значит, следующим этапом, очевидно, будет увеличение роли этого файла и уставки там появятся, и такая сейчас работа ведется. Когда-то и программируемая логика там появится. Но это все поэтапно, так как процесс длинный.

Модератор. Чайкин Вячеслав Сергеевич: Спасибо, коллеги! Но мы еще не спросили представителя заказчика. У нас на конференции Артем Владимирович Перепелицын, у которого есть опыт со стороны заказчика по реализации ЦПС. Нам сегодня проектировщики сказали, что заказчик не смотрит, производители сказали, что сами продиктовали заказчику свои условии, что они его обучили, и он уже сам то-то может, а наладчики говорят, что к их услугам прибегают.

А какой ваш опыт по приемке проектов ЦПС? Каких инструментов вам не хватало? Есть ли они сейчас на рынке и какие трудности были с приемкой цифровых проектов?

Перепелицын Артём Владимирович. Советник генерального директора ПАО «ФИЦ»: Заказчики бывают разные и степень компетентности специалистов заказчика, которые занимаются как приемкой проектов, так и приемкой объекта, разные. Поэтому за всех говорить очень сложно, могу говорить о своем опыте. Я, как заказчик, и электронный проект, и документацию, и сам объект принимаю с учётом SCD файлов, SSD файлов и так далее. Если по этой теме отвечать развернуто, то в отношении современных крупных объектов капитального строительства, которые строятся с нуля, есть смысл рассмотреть BIM-проектирование. И те вещи, которые уже реализуются в рамках чисто строительных проектов, на мой взгляд, можно и нужно применять и при строительстве объектов электроэнергетики. У меня есть крупный проект, который я сейчас веду, и в ТЗ на него есть BIM-проектирование, в том числе подстанции, но пока это работает не очень хорошо, так как сначала проектировщик делает традиционный проект, как все привыкли, а затем классические чертежи перерисовывает в BIM-модель.

Все то же самое происходит и в части электронного проекта в формате МЭК-61850. Сначала он делает традиционные вещи, например схему ИТС, а потом на это наслаивают SSD. И этот процесс по-прежнему, как и 5-10 лет назад, очень кастомный. Проектировщики, с которыми я работал и работаю, САПР не применяют, файлы эти собирают либо с помощью вендерных программных продуктов, либо вообще вручную. И все это также кастомно проверяется. Сейчас процесс проектирования выглядит именно так.

Процесс наладки и приемки пока выглядит примерно также. Потому что, как правило, наладчики на объекте все коммуникации достаточно серьезно корректируют для того, чтобы это работало, но иногда это происходит не на объекте, а в рамках производителя у него на заводе, если собирается комплекс. И принимается это примерно также без средств какой-то автоматизации. Мой опыт именно такой. Сейчас, наверное, коллеги могут меня поправить в том, что многое есть, многое существует, но вот в реальных своих проектах я, к сожалению, таких вещей применить не смог, хотя очень старался, даже вписывал это в ТЗ.

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

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

Изменения эти идут, но идут небыстро и, наверное, не стоит ожидать, что мы завтра перейдем на все это. Постепенно появляются требования в ТЗ, и к ним постепенно привыкают проектировщики. Лет через 5, наверное, действительно мы более или менее на такой подход перейдем. Такой ответ, наверное, не совсем на тот вопрос, скорее мысли вокруг твоего вопроса.

Модератор. Чайкин Вячеслав Сергеевич: Я хочу зачитать то, что в комментариях в чате прилетело. О том, что в первую очередь инициатива должна исходить от заказчика и прописана в ТЗ. Так как иначе проектирование идет по проторенной тропе. Заказчик сам вписывает в ТЗ требование о том, какие схемы должны быть разработаны. Если написано, что нужна схема ИТС, то проектировщик ее делает.

Перепелицын Артём Владимирович: Это очень правильный комментарий и я приведу конкретный пример. У меня сейчас открыто мое ТЗ на текущий проект и там написано: «В том числе для каждой подстанции выполнить разработку файла электронного проекта SSD с описанием однолинейной схемы». То есть в соответствии с МЭК-61850 в редакции 2. Но процесс все равно строится именно так, как я сказал в начале. Сначала традиционный проект, потом на него наворачивается SSD, а не SSD, из которого потом можно выгрузить «однолинейку». Реальность у меня такова, не знаю как у других.

Модератор. Чайкин Вячеслав Сергеевич: Алексей Олегович, как должно проектирование измениться? И должно ли вообще измениться?

Аношин Олег Анатольевич: Очевидно, что проектирование должно измениться. Здесь проектировщиков не очень много, и мне кажется, что у нас некий камерный круг. Но, тем не менее, как сейчас проектирование идет? Существует два варианта, либо компания из одного директора со студентами на аутсорсинге, либо это проектный институт, так или иначе, с аффилированной или дочерней структурой, какого-то крупного производителя. Очевидно, что во втором случае проекты идут более или менее нормально, а в первом случае как бы всегда буксует. Как это должно поменяться? Как я уже сказал, что цифровая модель должна стать первичной, то есть должна быть не бумага первичная, а цифровая модель. Это очевидно. Даже по опыту нашей компании, в которой вроде как все молодые и цифровые, могу сказать, что все равно люди больше любят в Word табличку напечатать. Вместо того, чтобы пойти и заполнить ее, условно говоря, в специальном инструменте, потратить время на его освоение, чтобы потом это делалось все автоматически. Поэтому надо осознавать то, что цифровое проектирование на первом этапе требует больших инвестиций, которые всегда сопряжены с проблемами, что-то не работает, где-то не соответствует и так далее и тому подобное.

Те, кто сейчас это дело осваивают, как Алексей Дымшаков, они все равно сталкиваются с косяками. Там нет того, нет сего, это работает не так и так далее. Но те, кто это освоит сейчас, через 5 лет будут на коне, а те, кто будет осваивать через 5 лет уже опоздают.

Перепелицын Артём Владимирович: Можно я Алексея Олеговича дополню мелким нюансом. У меня, например, по текущему проекту госэкспертиза, в которой история с цифровым проектированием не очень интересна. SSD файлы? О чем вы? А вы понимаете что госэкспертиза, если она предусмотрена по проекту, это очень важный этап. И в том числе мне, как заказчику, это очень важно. И вот здесь, когда сталкиваются интересы моего желания, как заказчика, получить цифровой проект и получить положительное решение госэкспертизы, то нужно расставлять приоритеты для проектировщиков. Что важнее получить красивый цифровой проект или положительное решение госэкспертизы? Дальше каждый заказчик решает сам.

Аношин Олег Анатольевич: Я абсолютно с этим согласен и более того, будем откровенны. Мы работаем в супер зарегулированной отрасли, где каждое твое желание противоречит какому-то нормативному документу. И нам приходится с этим мириться. Да, конечно, если у тебя горит проект, а мы с вами знаем, как это в реальности бывает, как у нас в этой ситуации вводят подстанцию, которую потом отправляют в ремонт еще на год и доделывают.

Поэтому это неизбежность и тут комплекс вопросов. У нас постоянно горят сроки, все надо сдать вчера и значит на инновации времени нет. И это общая, комплексная проблема. Это первое.

Второе – это отстающая, несоответствующая потребностям «нормативка». Это наша данность, с ней надо просто работать и все. Сравнивая с опытом внедрения цифры на остальной части мира, то у нас не все так плохо. В целом мы нормально развиваемся, проекты делаем, опыт нарабатываем, даже есть, что показать наружу, есть чем поделиться, в частности опытом, который наработан в части создание профиля. Мы его обсуждаем на рабочей группе в рамках «Task Force» , которая «Basic Application Profile» МЭК-61850 разрабатывает. Ну как бы «Guidelines». Поэтому опыт накапливается, работа идет, просто сейчас становится понятно, насколько это большой и тяжелый пласт, который надо постепенно поднимать и разворачивать.

Модератор. Чайкин Вячеслав Сергеевич: Большое спасибо за мнение. Коллеги, тогда у меня вопрос в продолжение основного: «Нужно ли изменить подход к проектированию и гипотеза о том, что нужно начинать с цифровой модели. Вы с этим солидарны или нет?»

Антонов Дмитрий Борисович: Я не могу не согласиться с коллегами со сказанным ими ранее. ЦПС для отрасли, к сожалению, это пока скорее обуза и проблема. То есть о них мы пока говорим, как о некоем сдерживающем факторе. Пока мы на этапе, когда для всех это некая трудность и ее нужно преодолеть.

Что касается схем работы, то мы пока наблюдаем такую картину. Появляется некий проектировщик, зачастую крайне некомпетентный, это студент и директор, либо организация, которая еще не изучила инструментарий, не готова работать с цифрой. Они интересуются, спрашивают, но прямо сейчас взять и сделать не могут. Дальше они рисуют проект по классической схеме, то есть в AutoCAD, на бумаге свою часть прорисовывают связи, GOOSE и все остальное тоже в таблице. И затем в роль вступает уже основной производитель, большая часть оборудования которого применяется. Он тем или иным способом, на САПР, вручную, соответственно, реализует электронный проект, и он же в большей части производит наладку. Это то, с чем мы сталкивались. Поэтому необходимо разорвать эту пагубную цепочку. Проектировщики должны выпускать готовый продукт, который можно передать наладчикам и реализовать подстанцию, не используя производителя.

И вот к этому мы сейчас двигаемся, но мы только в начале пути. Поэтому предстоит большая работа и я с коллегами согласен, что со временем основой должен стать электронный проект. Никуда не денется и классическая часть, это питание, это расстановка шкафов, но это должно быть в меньшей степени, потому что, на ЦПС объем информации, передаваемый в цифре, гораздо больше, нежели физически остающееся оборудование. У меня такое мнение.

Модератор. Чайкин Вячеслав Сергеевич: Олег Анатольевич, вы можете ваше мнение по этому вопросу выразить?

Аношин Олег Анатольевич: Я повторюсь, что у нас опыт работы с сетевыми компаниями не очень удачен, но, что касается промышленных предприятий, то здесь все гораздо лучше. Дело в том, что промышленные предприятия ЦПС воспринимают как некое готовое решение, которое они получают на основании технического задания на проектирование. И они разыгрывают тендера не на основе поставки оборудования, не на основе опросных листов, не на основе технических требований к оборудованию, которые рождаются уже в результате проекта, а на основе технического задания на проектирование. И для них ЦПС – это как покупка дорогостоящего автомобиля, когда на выходе от заказчика есть техническое задание, а на входе есть готовые решения, причем это решение, которое уже работает и, которое только нужно проверить прямо на заводе-изготовителе. И задача проектной организации, которая часто бывает при этих промышленных предприятиях, зачастую сводится к привязке строительной части данного решения, которое хочет видеть промышленное предприятие. Поскольку в строительной части существует огромное количество нормативных документов, СНИП, которые, собственно, потом и проверяются в части госэкспертизы, то проектная организация, как правило, берет на себя эту функцию, а то, что называется функционалом самой подстанции, то это отдается на откуп организации или предприятия, которое выигрывает тот или иной тендер. И как раз в этой части значительно проще бывает работать, так как мы проектируем и изготавливаем оборудование, и мы же потом его налаживаем и сдаем заказчику. Это очень нравится заказчику, потому что он работает с одной организацией и только одна организация несет ответственность за готовое решение.

В «Россетях» немного другая технология, когда весь этап разбивается на отдельные процессы. То есть на процесс проектирования, изготовления, наладки, приемо-сдаточных испытаний оборудования и здесь мы сталкиваемся с теми проблемами, о которых я уже говорил. В ряде случаев есть не очень компетентные проектировщики, имеются сложности интегрирования в проекты оборудования различных вендоров. И подружить их между собой не всегда бывает организационно возможно, чтобы компании «Прософт», «ЭКРА» или «РАДИУС Автоматика» приехали к нам на завод и вместе тут поработали. И в этом есть определенная проблема. Все тоже самое, когда речь идет о проектировании. Достаточно часто сталкивался с тем, что тот или иной вендор готов разработать SCD файл только в части своего оборудования, но в части соседнего нет. И как тогда составлять общий проект? Это первый момент. Второй момент. Наш опыт говорит о том, что для разработки SCD файла все равно нужны некие схемные решения завода-изготовителя, потому что надо понимать как организовать, скажем, подачу на цепи, на дискретные входа/выходы, подключения тех или иных исполнительных органов и сигнализации. И поэтому все равно приходится это делать, как правило, сначала на бумаге, а уже потом на это накладывать цифровое решение.

Сделать так, чтобы начало было все электронное, а потом уже схемотехническое, наверное, возможно будет тогда такие САПР, как EPlan, ECube или ряд других, наряду с функционалом разработки схемных решений, будут предлагать функционал разработки цифровых решений.

И когда мы сумеем совместить это в пределах одного САПР, то тогда все встанет на свои места. А пока САПР разные то обязательно включается некий субъективный фактор. Как удобнее делать? Если сначала удобнее сделать традиционные решения, а не наложить цифру – значит, будем делать так. Если удобнее сделать наоборот, то будут делать наоборот. Но результат, если он в конце концов один и тот же, то, наверное, здесь можно работать и так, и так.

Дымшаков Алексей Викторович: Я философски подойду к этому вопросу. Чтобы это все заработало должны измениться все. Заказчики должны у себя, во-первых, персонал иметь квалифицированный, во-вторых, инструментарий, который просто может этот проект оценить и, например, хотя бы на ТЗ выкладывать уже готовый SCL файл. В этом же плане должны измениться и проектировщики. Поставщик должен опять же все у себя это поддерживать. Если все мы изменимся, то и госорганы должны измениться, потому что та же экспертиза проекта, если он цифровой, то значит, у них должны быть средства, чтобы его оценить, иначе он все время будет на бумаге. Наверное, как-то так.

Модератор. Чайкин Вячеслав Сергеевич: Алексей, измениться надо даже на основании комментариев Олега Аношина., а есть ли в мыслях рецепт, а в какую сторону то измениться?

Дымшаков Алексей Викторович: В принципе, Андрей Сергеевич Шеметов идет правильным путем. Если у нас был хотя бы бесплатный САПР, которым можно было бы создать и цифровой проект и рабочую документацию, то это был бы уже большой шаг вперед, потому что этот САПР мог бы взять проектировщик, заказчик и производитель, хотя бы для того, чтобы посмотреть, что там нарисовано. На одном языке надо научиться разговаривать, а тогда уже можно будет договориться.

Модератор. Чайкин Вячеслав Сергеевич: Николай Зайцев, вы как проектировщик скажите, как вашей работе нужно поменяться для того, чтобы быстрее прийти к ЦПС и не дублировать решения из бумаги в цифру и наоборот.

Зайцев Николай Юрьевич: Тут вопрос больше в том, как будет это принимать заказчик. Если он готов принимать в виде SCD и то, что у нас, допустим, от классического проектирования останется, к примеру, расположение оборудования, и все идет в электронный формат, то тогда здесь как бы требование самого заказчика. То же самое РДУ. Я сомневаюсь, что оно выйдет. Может быть, когда-нибудь мы к этому придем, но пока на данный момент мы от бумаги, от тех же самых списков сигналов, которые они требуют. «ФСК» сейчас это в каком-то виде уже автоматизировал, но мы пока не можем никак от этого уйти. То есть, как коллеги сказали, что разработал файл, отправил его, и на этом все закончилось, тут так не получается.

Модератор. Чайкин Вячеслав Сергеевич: Коллеги, спасибо. Интересные прозвучали мысли. И последний вопрос, на который достаточно ответа из двух слов для каждого из вас. Вопрос от зрителя: «Как вы думаете, в какой области кривой Гартнера, варианты ответов - бурный рост, пик завышенных ожиданий, разочарование или плато эффективности, находится сегодня технология цифровой подстанции?». Я дополню – отношение к проектированию в том числе.

Аношин Олег Анатольевич: Я думаю, что мы все-таки сейчас находимся где-то внизу. В процессе перехода от разочарования к нахождению решений, эффективных решений, потому что процесс разочарования, мне кажется, уже пройден.

Перепелицын Артём Владимирович: Я не готов мыслить именно теми категориями, в которых задан вопрос. Мне кажется, что мы сейчас находимся на стадии роста этих технологий и роста внедрений, и мы не достигли плато, то есть этими технологиями наш рынок явно не насытился. На сегодняшний день мы не пришли к каким-то стандартным типовым решениям.

Модератор. Чайкин Вячеслав Сергеевич: У вас еще разочарования не произошло и ожидания по-прежнему завышены? Или все-таки ожидания уже сравнялись?

Перепелицын Артём Владимирович: Я вообще не люблю слово «разочарование», у меня есть здравый скепсис к этим технологиям. Я изначально к ним не относился как к волшебной палочке, которая решит нам все проблемы. Это просто технологии, которые в будущем позволят нам получить некоторые положительные моменты. Не более того. И сейчас мы пытаемся эти технологии грамотно внедрять. Пока не очень получается.

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

Модератор. Чайкин Вячеслав Сергеевич: Николай, вы разочаровываетесь, когда видите в ТЗ требование «предоставить SCD файл»?

Зайцев Николай Юрьевич: Да. Раньше разочаровывался, сейчас уже нет.

Аношин Олег Анатольевич: Я тоже, наверное, буду солидарен со всеми высказавшимися, но мне кажется, что для разных людей, кто в разный момент с этим столкнулся, все будет по-разному, но в среднем, мне кажется, мы прошли дно и потихонечку идем вперед.

Антонов Дмитрий Борисович: Мне кажется, что прошел этап лозунгов, когда красивые картинки рисовали на различных семинарах. Было разочарование, когда люди впервые попробовали и поняли, что не все так красиво, как описано в теории. Сейчас у нас есть определенные результаты, я имею в виду в отрасли вообще, то уже есть опыт и, наверное, сейчас действительно зона роста, когда наращиваются технологии. Скорее всего, где-то будет очередной этап разочарования и придется пересмотреть парадигму, но это впереди.

Дымшаков Алексей Викторович: Как говорится: «С палачом без палача, а дело то надо делать». Только вот какое? По 2-й архитектуре, считаю, рост идет, а по 3-й какая-то непонятная ситуация. То ли разочарование, то ли ещё что-то.

Модератор. Чайкин Вячеслав Сергеевич: Я понял. В общем, сколько архитектур и вариаций, столько кривых Гартнера нужно нарисовать. Коллеги, спасибо, было очень интересно. Надеюсь, встретимся в этом и более расширенном составе в ближайшем будущем. Благодарю за ваши мнения!

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

Большое спасибо! Желаю вам удачи! Достигнуть плато коронавируса, пережить его и быть здоровым! До свидания!