Дата публикации: 23.09.2019
Метки: Технологии | Проекты | Решения

Опыт разработки электронных проектов цифровых подстанций

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

Андрей Майоров, «Россети»

Мы подготовили основополагающий документ по стандарту цифровой подстанции. Он сейчас находится на рассмотрении и согласовании в Минэнерго. Все наши дочерние общества и компании энергетического сообщества «прошли» этот стандарт. Мы получили порядка 400 замечаний и предложений, практически все их учли и отдали в Минэнерго для согласования и подтверждения легитимности документа.

На основе этого документа со второго квартала все новое проектирование будет базироваться на новом стандарте. Все подстанции, которые в настоящее время строятся в аналоговом формате, будут переоборудованы под цифровые в 2020–2021 годах. Все то, что проектировали раньше, — мы достраиваем в этом или следующем году. Вводим в эксплуатацию и переоборудуем в период 1–1,5 года, доводим до цифровой подстанции.

Однако это не так просто — сделать цифровой проект! Нам показалось интересным спросить об этом самих проектировщиков, которым задали пять вопросов:

Какой опыт вы имеете в разработке электронных проектов цифровых подстанций?
Какие программные инструменты вы используете для разработки цифрового проекта на разных стадиях: на стадии ОТР/ПД (разработка SSD) и РД (разработка SCD)?
С какими проблемами сталкивались при разработке цифрового проекта на различных стадиях и как удавалось их решать?
Какая реакция на разработанные цифровые файлы была от заказчика: выдавались ли замечания по ним или документация принималась формально?
В каких направлениях, на ваш взгляд, требуется совершенствование, и в чем оно должно заключаться (например, в области нормативного регулирования, разработки программных инструментов и т. д.)?

Андрей Арсентьев, Главный специалист — заведующий сектором автоматизированных систем, НПП «Экра»

Разработку SSD/SCD по требованию заказчика в проектах мы ведем с 2017 года.
Первые опыты внедрения оборудования с поддержкой SV-потоков со стороны НПП «ЭКРА» начались в 2014 году. На тот момент стало понятным, что в скором времени потребуются проекты полностью цифровых подстанций. Так как НПП «ЭКРА» помимо оборудования также занимается и разработкой программных продуктов, был разработан свой программный продукт. Он и был использован в последних проектах по цифровым подстанциям для разработки SSD/SCD. В «ознакомительных» целях мы как проектировщики также использовали программное обеспечение стороннего производителя для создания документа SSD. В последующем открывали файл при помощи собственного программного продукта, тем самым оценивали возможные вопросы со стороны будущих заказчиков, которые могут использовать сторонние программные продукты.
Начнем с простого. При наличии программного обеспечения разработать SSD не сложно. Зная правила создания файла формата xml, можно даже попытаться, как настоящий программист, написать код в «блокноте», но при наличии пробных версий ПО такой подход уже неразумен. Условно проблемой можно выделить наличие согласованной схемы распределения ИТС. Файл описания спецификации системы не отменяет существующие нормы проектирования. Все знают, что с внедрением электронного документооборота расход бумаги не уменьшается, а бывает, и увеличивается, так как каждый начинает делать себе бумажную копию письма. Мысль заказчика и эксплуатации ясна: файл SSD — хорошо, но схема ИТС с подписями не помешает. Второй шаг — разработка SCD-файла описания конфигурации подстанции: здесь потребовалась совместная работа специалистов РЗА и АСУ, как проектировщиков, так и наладчиков. Есть вариант взять файлы .ICD и файл .SSD, при помощи ПО для конфигурирования системы создать файл .SCD, но в последующем Plug and Play, чего хочет заказчик, не удастся. Проблема или нет решает каждый, но проектировщик должен расширить требования к себе и знать основы наладки.
Если говорить о двух проектах, по которым в настоящее время на подстанциях идет опытная эксплуатация, то они проходили в рамках НИОКР, и заказчик контролировал весь процесс, начиная с написания технического задания. Файл .SCD проверялся ПО стороннего разработчика, и в первых редакциях замечаний было много. При их исправлении мы набирались опыта, что в последующем поможет нам сэкономить время в проектировании новых ЦПС.
Сам вопрос подсказывает ответ — совершенствование нужно в области нормативного регулирования. К примеру, ФСК проделана большая работа, разработаны:

типовые архитектуры АСУ ТП для ПС,
требования к типовым шкафам АСУ и РЗА,
требования к оборудованию ЦПС,
свой профиль по IEC 61850.

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

Денис Афанасьев, Системный архитектор IEC 61850, «Теквел»

Наш опыт разработки электронной проектной документации достаточно обширен, и на сегодняшний день включает разработку электронной проектной и рабочей документации для 15 проектов ПС классом напряжения 110 кВ, среди которых для 10 ПС была разработана электронная проектная документация для стадии ПД (SSD-файлы) и для 5 проектов как ПД (SSD-файлы), так и РД (SCD-файлы). Стоит отметить, что многие из этих работ мы выполняем по подряду и в тесном сотрудничестве с проектными организациями, разрабатывающими полный проект ЦПС и не имеющими достаточной квалификации в выполнении цифрового проекта. Кроме проектирования под конкретные проекты, наша компания выполняла целый ряд НИОКР по теме цифрового проектирования по заказу ПАО «ФСК ЕЭС» и ДЗО ПАО «Россети», в рамках которых разрабатывались наборы типовых элементов SSD-файлов. Также следует отметить, что в рамках внутренних НИОКР компании «Теквел», проводившихся в 2013–2014 гг., выполнялись работы по проектированию элементов ПС 500 кВ в соответствии с принципами выполнения электронного проекта по стандарту IEC 61850 с использованием специализированных САПР. Эти работы еще на ранних стадиях позволили выявить особенности проектирования объектов в «цифре» и сформировать необходимые компетенции, использующиеся сегодня в конкретном проектировании.
В рамках создания SSD- и SCD-файлов мы используем комбинацию инструментов, поскольку, по нашим наблюдениям, на сегодняшний день на рынке, к сожалению, отсутствует программный инструмент, который бы позволил решить все возникающие задачи «из коробки». Основой для создания SCL-файлов на стадии ПД, в ходе которой разрабатываются SSD-файлы, являются инструменты собственной разработки компании, и частично выполняется «ручная» доработка SSD-файлов. Внутренняя приемка файлов на этапе SSD выполняется с использованием разработанного нами же инструмента для структурированного отображения SSD-файлов, размещенного на ресурсе iec61850.ru. Как правило, этот же инструмент мы предлагаем нашим заказчикам для осуществления приемки. Разработка SCD-файла — это существенно более сложная задача, для которой в работе, помимо собственных инструментов, применяются также и инструменты отдельных производителей (в частности, для выполнения специфических задач параметрирования, характерных для конкретных устройств). В качестве инструмента для внутренней приемки SCD-файлов мы используем «Теквел Парк».
Как правило, на этапе разработки SSD-файла проблемы минимальны, так как, по своей сути, SSD-файл описывает однолинейную схему энергообъекта с присвоенными логическими фикциями (типами логических узлов). Единственная трудность, которую хотелось бы выделить, — это определение перечня проектируемых логических функций отдельных участков и элементов энергообъекта в соответствии со стандартом IEC 61850. Данная проблема возникает на ранних стадиях проектирования и разрешается запросом дополнительной информации по проекту или согласованием перечня логических функций с ответственным лицом проектной организации. С SCD-файлом проблем значительно больше. Так как SCD-файл является точкой сопряжения видений стандарта IEC 61850 различных производителей (как зарубежных, так и отечественных), то логично предположить, что основной перечень проблем и трудностей возникает именно по этой причине. Также при описании модели данных устройства как проблему хотелось бы выделить частое использование производителями логических узлов GGIO. Подобный подход не позволяет описать устройство и его функциональные возможности так, как этого требует стандарт IEC 61850. Еще одна проблема — это распознавание конфигурации устройства из SCD-файла специализированным ПО ИЭУ и последующая загрузка CID-файла в само ИЭУ. Данная проблема может возникать из-за программных ограничений, излишнего использования Private-элементов в распознавании конфигурационных файлов конфигуратором ИЭУ и прошивкой ИЭУ или из-за индивидуального способа описания конфигурации устройства производителем. Исходя из этого, на данный момент оптимальное решение подобных проблем, во-первых, валидация файлов конфигурации устройств (ICD, IID, CID) перед добавлением в электронный проект, а во-вторых, — как ни странно — визуальная проверка содержимого конфигурации с последующим обсуждением спорных моментов с производителем.
Нельзя сказать, что реакция всех заказчиков абсолютно идентична, но в основном электронная проектная документации воспринимается ими как нечто новое и неизведанное, то, что перед анализом и формированием перечня замечаний требует изучения предмета обсуждения. Часто бывает так, что от заказчика выделяется один или несколько специалистов, ответственных за приемку файлов электронной проектной документации. И в первую очередь мы пытаемся связаться с ними и рассказать, что это такое, как читать электронную проектную документацию и какими инструментами пользоваться для ознакомления с ней. В случае, если представители заказчика желают более глубокого ознакомления со стандартом IEC 61850, мы довольно-таки часто проводим семинары, где подробно рассказываем и обсуждаем все моменты, связанные с интересующей темой. Отсюда можно сделать вывод, что реакция на электронную проектную документацию напрямую зависит от знаний ответственных представителей заказчика в части стандарта IEC 61850.
В первую очередь надо понять, что IEC 61850 — это, прежде всего, именно стандарт, и по своей сути он подразумевает некую систему требований и единообразный подход к решению поставленных задач. Отсюда следует, что основное направление деятельности, требующее развития, — это унификация программных и аппаратно-технических решений от разных производителей, а также полная совместимость в части коммуникаций по стандарту IEC 61850. И первый шаг, который обеспечил бы реализацию данных условий, является единообразный подход в описании модели данных устройства вне зависимости от производителя. При этом под единообразным подходом описания модели данных устройства мы понимаем и единообразное описание функций с использованием логических узлов, и типовые структурные схемы взаимодействия узлов между собой — то есть, по сути, применение единого прикладного профиля стандарта IEC 61850 с учетом всей специфики реализации функций, присущей российской электроэнергетике. Благодаря этому может быть достигнуто упрощение процесса обслуживания и эксплуатации систем энергообъекта.

Алексей Костюк. Начальник отдела АСУ ТП и ТМ, «ДонСетьСтройПроект»

1. До сего дня нами проектировались две цифровых подстанции для одного из ДЗО «Россетей». При этом вопросы разработки SSD- и SCD-файлов заказчик делегировал поставщикам РЗА и АСУ ТП.

2. В настоящий момент наши отделы, разрабатывающие АСУ ТП, РЗА, ПА и т. п., еще только присматриваются к существующим средствам САПР для ЦПС.

3. Проблемы возникают, в первую очередь, при использовании оборудования от разных поставщиков, например, РЗА и АСУ ТП/ССПИ. Проблемы связанны с:

совместимостью,
правами на использование ресурсов ЛВС и распределением между системами функционала архивирования/визуализации/ретрансляции.

Все это приводило к открытым конфликтам, зафиксированным в официальных переписках. В связи с тем, что подобные проблемы всплывают на этапе ПНР, решением этих противоречий заказчик занимался сам.

Эта ситуация — следствие отсутствия во всех ДЗО «Россетей», кроме, пожалуй, ФСК, практики взаимного согласования проектной документации между проектировщиком и поставщиком.

Есть проблемы с разделением зон ответственности за вторичные системы ЦПС, желание служб иметь монопольное право на использование аппаратных средств, что в свою очередь приводит к наличию в составе ЦПС устройств весьма странного назначения и исполнения. К примеру, по требованию разделов РЗА одного из ТЗ на ПС предусматривалась установка сервера РЗА/сервера ЦПС/сервера РАС ЦПС. В другом случае предусматривалась установка сервера РАС/сервера мониторинга цифровых потоков/сервера ЦС. При этом в обоих случая в ТЗ весьма пространно описывались требования к функционалу этих устройств и полностью игнорировался функционал оборудования АСУ ТП.

Как мы понимаем, природа подобных требований проистекает, во-первых, из недоверия эксплуатации (в первую очередь, служб РЗА) к новым методам взаимодействия вверенных им устройств и попытки создать в составе ПАК ЦПС некий «черный ящик», пишущий все, что происходит в ЛВС ЦПС. При этом доходит до абсурда — вроде хранения SV-потока за три года! А во-вторых, это проистекает из необходимости интегрировать ПАК ЦПС с кустарными и зачаточными системами обмена неоперативной технологической информацией (серверы РЗА уровня ЭС, системы сбора данных РАС).

Нужно отметить, что вопросы сбора и передачи неоперативной технологической информации — наиболее, на наш взгляд, болезненные как на практическом, так и на нормативном уровне. (ФСК в этих, как и во многих других, вопросах — исключение.) ЦУС в большинстве не готовы принимать технологическую информацию, в НТД вопросы создания АСТУ разных уровней не проработаны. Непонятно, каким именно службам необходимы данные, к примеру, от СМТО. Все это приводит к размытию положения АСУ ТП как средства функционирования единого информационного пространства всего энергообъекта — что наиболее заметно при архивировании и визуализации осциллограмм, по которым у каждого раздела ТЗ свое представление.

Хотелось бы отметить, что данная ситуация будет только усложняться, так как проект «Типовое задание на проектирование цифровой подстанции» относит создание ЛВС ЦПС к разделам связи. Таким образом, к процессу согласования проектной документации ЦПС подключается еще одна служба!

4. Как мы понимаем, заказчик не обладает программными средствами и людскими ресурсами, чтобы полноценно проверить предоставленные SSD- и SCD-файлы. Видимо, с этим связано появление в свежих ТЗ ДЗО ПАО «Россети» следующего требования: «Электронная проектная документация формата SCL должна в обязательном порядке сопровождаться визуально-графическим материалом с описанием всех значимых параметров конфигурации, а также путями передачи данных» («Типовое задание на проектирование цифровой подстанции 110 кВ ДЗО ПАО „Россети“», п. 5).

5. Требуется значительная доработка НТД в части конкретизации требований к архитектуре и функционалу ЦПС (вплоть до разработки типовых проектов). На текущий момент НТД содержат множество противоречий даже внутри отдельных документов. Пример: проект СТО 34.01-хх.х-00х-2019 «Цифровой питающий центр. Требования к технологическому проектированию цифровых подстанций напряжением 110–220 кв и узловых цифровых подстанций напряжением 35 КВ» v3.0 в п. 8.20 предписывает: «При проектировании цифровой ПС в качестве целевой архитектуры должен приниматься вариант с использованием кластера серверов в качестве аппаратной платформы для ПТК уровня присоединения». А в п. 22.4.1: «Уровень присоединения АСУ ТП должен образовываться интеллектуальными электронными устройствами (контроллерами присоединений)». В разделе 21 (РЗА) подход схожий.

Что касается САПР, то, с точки зрения проектировщиков, перенос вопросов создания SSD- и SCD-файлов с наладчиков на нас (даже без учета вопросов покрытия дополнительных трудозатрат и издержек) выглядит весьма странным при отсутствии локализованного программного комплекса для проектирования.

Артем Кашин, Ведущий инженер отдела РЗА, «Северэнергопроект»

В данный момент проектируем несколько цифровых подстанций с использованием цифровых интеллектуальных устройств производства НПП «Экра».
Для разработки цифрового проекта на разных стадиях (ОТР/ПД и РД), а именно разработки SSD-и SCD-файлов, применялась программа SCL Express производства компании «Экра», а также редактор подстанции IEC 61850 производства «Радиус Автоматики».
При разработке проектов возникали проблемы с получением файлов описаний цифровых терминалов в формате icd. Кроме того, возникали проблемы со стабильностью программного обеспечения, а также трудности с алгоритмами работы в данных программных комплексах. Эти проблемы решались по горячей линии с технической поддержкой завода-изготовителя.
В первых наших проектах ЦПС заказчику выдавалась таблица обмена сигналами (GOOSE, SV, MMS-сообщения) между терминалами защит и преобразователями сигналов (аналоговых, дискретных). Документация тщательно проверялась заказчиком, который выдавал свои замечания, к примеру, по объединениям нескольких дискретных сигналов в одно GOOSE-сообщение или по присвоению ID-номеров, SV-номеров, MAC-адресов всем терминалам и всем преобразователям аналоговых (дискретных) сигналов.
На мой взгляд, требуется совершенствование интеграции работы предприятий-изготовителей и проектных институтов. Таким шагом может являться обучение персонала проектной организации на площадке завода-изготовителя, где проектировщика будут знакомить с окончательным программным продуктом. Также есть сомнения, что большинство заказчиков смогут проверить правильность составления SSD- и SCD-файлов, поэтому, на мой взгляд, в данные программные продукты необходимо включать функции автоматической проверки. Также полезно будет создание библиотек описания цифровых терминалов в формате icd.

Евгений Лепко, Ведущий инженер департамента проектирования, «Квадро Электрик»

В настоящий момент в нашей компании разрабатывается несколько проектов цифровых подстанций. Сейчас мы находимся в стадии разработки проектной документации.
В создании цифрового проекта было решено использовать отечественные САПР. Для разработки SSD-файла на одной из подстанций тестировали САПР ЦВК разработки В. А. Трофимова из МЭИ. Основным положительным моментом данного САПР можно назвать то, что принципиальная схема для SSD формируется в Avtocad (ZWCAD, GstarCAD, BricsCAD), что позволяет брать в работу файл однолинейной схемы, разработанный отделом первичных соединений в формате dwg. Также у программы достаточно простой и удобный интерфейс. Недостаток указанного САПР — несоответствие выходного SSD-файла второй редакции стандарта IEC 61850. Также в компании «Квадро Электрик» идет тестирование САПР ЦПС РА, разработки компании «Радиус Автоматика». О плюсах и минусах данного ПО пока говорить рано.
Первая проблема при разработке цифрового проекта, на наш взгляд, — корректность файлов и соответствие их требованиям IEC 61850 (правильное прочтение файлов xml машиной, а также проверка функциональных связей между ИЭУ, корректность сообщений GOOSE и MMS проектным требованиям). Но проблема может быть решена применением специальных валидаторов и визуализаторов кода (например, с использованием «Теквел Парк»). Вторая проблема — сложность расчета ЛВС на стадии проектирования. Из-за отсутствия нормативных отечественных методик расчета трафика заказчиками предъявляются различные требования по организации горизонтальных связей (GOOSE, как в шине процесса, так и в шине станции, и т. д.).
К сегодняшнему дню обратной связи от заказчиков еще не получено, документация находится на рассмотрении.
На наш взгляд, требуется совершенствование по следующим направлениям:

разработка и внедрение нормативно-технической документации с требованиями к содержанию электронного и традиционного проекта на цифровые подстанции,
разработка и внедрение типового «эталонного» цифрового проекта,
разработка и внедрение нормативно-технической документации с требованиями к проектированию цифровых ПС, структурам ЛВС,
наработка типовых проектных решений, пилотных внедрений и опыта эксплуатации ЦПС.

Но самое главное — у конечного заказчика должно выработаться понимание того, какой эффект дает применение технологии ЦПС. Пока что на местах задача цифровизировать «все и вся» стоит как указание сверху.

Олег Кузнецов, Главный инженер, «Самарский Электропроект». Дмитрий Тюрин, Главный специалист отдела электроснабжения, «Самарский Электропроект»

1–5. Мы выполняем проектные работы реконструкции объекта для одной из дочерних компаний ПАО «Россети». Согласно техническому заданию на проектирование очевидно, что сетевые организации до сих пор официально не определились с идеологией построения архитектуры цифровой подстанции, так как перед выполнением проектной документации требуется рассмотреть 9 различных вариантов построения ЦПС с оценкой капитальных затрат и надежности в части вероятности безотказной работы. Уже после выбора варианта построения ЦПС актуальные вопросы проектирования не завершаются, так как появляются новые, в том числе согласование работы систем и устройств различных интеграторов и изготовителей, а также другие вопросы.

На наш взгляд, в дочерних компаниях ПАО «Россети» отсутствует единый подход по построению архитектуры ЦПС, что отрицательно влияет на вектор развития построения надежной структуры ЦПС и развития новых технологий в данной сфере. Гарантия успешного внедрения цифровых подстанций — в едином подходе, который должен рождаться в совместных обсуждениях ведущих специалистов дочерних компаний ПАО «Россети» и НТЦ ЕЭС.

Кроме того, нельзя забывать о человеческом факторе, так как мало реализовать и запустить ЦПС инжиниринговыми компаниями, важнее обеспечить надежную эксплуатацию подстанции. При этом обостряется вопрос готовности кадров — в каждой электросетевой службе должны быть подготовлены (обучены) соответствующие специалисты, требования и уровень их компетенций во многом зависят от того варианта построения, который будет в итоге принят. А учитывая, что специалисты РЗА и область релейной защиты достаточно консервативны, а их профессиональные навыки, принципы и опыт работы обеспечивают высокую надежность электроустановки и электрической сети, важно не устраивать в этой сфере революций, а последовательно двигаться по эволюционному пути цифровизации электроэнергетики.

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

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

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

Михаил Шемякин, Инженер отдела АСУиИТ, «ВЭК»

В рамках компании «ВЭК» имею опыт разработки ЦПС около года.
Для разработки файлов SCD и SSD имеем опыт использования ПО SCT Tool, тестирования — ПО Atlan Designer.
Нет конкретной нормативной документации для обозначения сигналов GOOSE-сообщений срабатывания разных ступней защит и т. п. Решение, считаю, в добавлении области «prefix’а» для разных ступеней защит. Возможно для данной цели использовать «профиль» стандарта IEC 61850 ПАО «Россети», но его нет в открытом доступе. В нормативах IEC 61850 нет методик расчета нагрузки на сети «Шина процесса» и «Шина подстанции». По сути, сейчас производители устройств РЗА целиком предлагают структуру ЦПС (в части передачи данных) с учетом функциональных особенностей своего оборудования. Например, сеть «Шина процесса» используется только для передачи аналоговых значений тока и напряжения (SV-потоки).
Заказчик не умеет обрабатывать SSD-файлы (и тем более SCD-файлы), т. к. это тема для него является новой. Поэтому реакция была соответствующей.
Требуется усовершенствование в части прозрачности применения норматива для проектировщика — типовые расчеты нагрузки на ЛВС, обозначения сигналов и т. п., доступность программных продуктов для создания SSD- и SCD-файлов.

Ольга Абросимова, Главный специалист ОРЗА, «Альянсэнергостройпроект»

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

-------------------------------------------------------------------

Хотите оперативно узнавать о выходе других полезных материалов на сайте "ГИС-Профи"?
Подписывайтесь на нашу страницу в Facebook.
Ставьте отметку "Нравится", и актуальная информация о важнейших событиях в энергетике России и мира появится в Вашей личной новостной ленте в социальной сети.