В данном факте нет ничего неожиданного. И если на этапе внедрения первых пилотных проектов цифровых подстанций еще можно допускать возможность привлечения к наладке и запуску высококвалифицированных специалистов, то в дальнейшем, когда построение подстанций с применением стандарта МЭК 61850 станет нормой, процессы проектирования и внедрения должны существенно измениться. А именно - проектированием цифровой подстанции должны заниматься высококвалифицированные специалисты. Безусловно, они будут использовать соответствующий САПР, однако это не снимает с них ответственность за принятые частные решения. Проектировщик станет полноценным Архитектором. Именно он будет определять работоспособность решения и, безусловно, отвечать за это. В свою очередь, должны перераспределиться затраты на реализацию цифровой подстанции. Стоимость проектирования увеличится, но вместе с этим стоимость пусконаладочных работ должна снизиться. Стоимость монтажа также должна сокращаться: за счет уменьшения расходных материалов, снижения объема кабельной продукции и соответственно - объема работ по ее прокладке и расключению. В любом случае нельзя забывать главной цели внедрения стандарта - оптимизация и уменьшение затрат на создание и эксплуатацию новых подстанций. Если же стоимость цифровой подстанции будет выше, чем традиционной (проект, работы, оборудование, обслуживание), то "игра не стоит свеч".
Появление в составе документа "Нормы технологического проектирования подстанций переменного тока с высшим напряжением 35-750 кВ" (НТП ПС) требования о включении файла описания подстанции в формате SCD при проектировании и строительстве цифровых подстанций - это давно ожидаемое событие. Однако нельзя не отметить тот факт, что в предложенном виде это требование работать не будет и не принесет пользы ни компаниям, занимающимся проектированием подстанций, ни системным интеграторам, ни в конечном итоге предприятиям ОАО "ФСК ЕЭС". К сожалению, если проследить эволюцию НТП ПС, можно отметить, что внедрение норм МЭК 61850 происходит в порядке, обратном логике самого стандарта. Сначала указали на необходимость использовать протоколы MMS и GOOSE для связи устройств РЗА и АСУ ТП, а спустя 5 лет появляется требование выдавать описание подстанции в формате SCL. Если новое требование останется в том виде, как оно есть сейчас, то единственным его следствием будет увеличение трудоемкости разработки проектной документации и появление еще одного не нужного документа в составе проекта. В пользу этого можно привести несколько аргументов:Вывод. Само по себе внедрение требований следованию стандартом МЭК 61850 при проектировании подстанций - это необходимый и оправданный процесс. Однако, для получения полезного эффекта необходим более последовательный и осмысленный подход, чтобы избежать ситуации когда работа делается не ради результата, а ради самого процесса работы.
- Всем специалистам известен основной бич стандартов серии 61850 - это многовариантность исполнения практически любого пункта стандарта. В отсутствие ограниченного набора вариантов реализации всех основных аспектов затронутых стандартами МЭК 61850, файл описания спецификации подстанции (SSD) не возможно будет применить в ходе рабочего проектирования, так он вероятнее всего окажется не совместимым со специализированным программным обеспечением производителя РЗА или АСУ ТП.
- В процессе проведения пусконаладочных работ на реальных подстанциях файл SCD может меняться несколько раз в течении одного рабочего дня. Тем самым ко дню сдачи подстанции эксплуатацию, разработанный в составе рабочей документации файл уже будет отдаленно похож на работающую конфигурацию системы. А теперь представим, что не опытный или просто запутавшийся инженер РЗА воспользуется этим файлом при прошивке нового или отремонтированного терминала на действующей подстанции.
С одной стороны, такое требование имеет основание со ссылкой на МЭК 61850-4 и, если действовать по стандарту, по-другому и не должно быть.
На наш взгляд, для ответа о целесообразности применения сейчас таких требований следует произвести оценку некоторых факторов. Например, достаточный ли уровень подготовленности и опыт работы имеют в настоящий момент проектные организации для выполнения данного требования? Отсутствие того или другого может привести к тому, что выдаваемые заказчику файлы конфигурации могут быть неработоспособными.
Другой, на мой взгляд, немаловажный фактор – присутствие отечественного программного обеспечения для создания таких файлов. Здесь следует учесть сложившуюся обстановку и учитывать возможное влияние санкций.
На наш взгляд, учитывая все выше перечисленное, выдвижение такого требования сейчас может быть несколько преждевременным, стоит накапливать опыт.
Создание файла описания конфигурации подстанции SCD в формате языка SCL в соответствии с МЭК 61850-6 на стадии проектировании - это цель, к которой надо стремиться. Но сейчас прописать это требование в нормах проектирования - не правильно. Это все равно, что сказать: Завтра летим на Марс… громко, красиво, но не серьезно.
Понятно, что к цифровому проектированию надо стремиться и делать определенные шаги в этом направлении. Уже лет через пять классическое (бумажно-ручное) проектирование энергообъектов станет бутылочным горлышком, которое будет тормозить наш технологический прогресс и не позволит нам идти в ногу с современными технологиями.
Мое мнение, вначале необходимы пилотные проекты, где параллельно будет обычное проектирование и полностью цифровое. Провести полный цикл данной работы от принятия решения о расширении энергосистемы в данном районе до промышленной эксплуатации подстанции. Это как минимум три года. По итогам будет ясно, как идти к заветной цели и какие документы, в соответствии с законодательством РФ, придется делать «по старинке». Когда будут реальные решения, опробованные практикой – можно и нужно прописывать все это в требованиях.
А вот про введение раздела по выбору параметров настройки локальной сети, полностью согласен, что это нужно обязательно и прямо сейчас! Информационные сети современные подстанций уже не просто большие, они гигантские, и без грамотного проекта их настроить уже не возможно.