ru
ru en

Рабочая документация должна сопровождаться файлом SCD

Новая редакция стандарта организации ОАО "ФСК ЕЭС" "Нормы технологического проектирования подстанций переменного тока с высшим напряжением 35-750 кВ" может обязать проектировщиков в составе рабочей документации передавать файл описания конфигурации подстанции SCD в формате языка SCL (System Configuration Language) в соответствии с МЭК 61850-6. На данный момент документ не введен в действие.

SCL

Выдержка из документа:

SCLRequirements

При этом речь идет не только о создании файла SCD, но и также о создании файла SSD – на стадии разработки проекта.

Напомним, что файл SSD (Substation или System Specification Description) описывает однолинейную схему объекта и распределение логических узлов, соответствующих функциями РЗА, мониторинга и т.д., по этой схеме. Упрощенно – можно сказать, что это некое подобие разрабатываемой сегодня схемы ИТС.

Файл SCD (Substation или System Configuration Language) описывает обмен между физическими устройствами по определенным коммуникационным сервисам стандарта МЭК 61850: GOOSE (быстрая передача аналоговых и дискретных сигналов между устройствами), Reports (спорадическая передача данных от терминалов РЗА в АСУ ТП), Sampled Values (передача мгновенных значений тока и напряжения от устройств сопряжения с шиной процесса в терминалы РЗА и контроллеры присоединений) и др.

Насколько это нужно?

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

Настройки таких коммуникационных сервисов, как GOOSE и Sampled Values должны быть согласованы с настройками коммутаторов, карта параметрирования которых также должна разрабатываться на стадии РД. Указанное должно быть выполнено для ограничения неконтролируемого распространения трафика GOOSE и Sampled Values. Когда релейщик сегодня создает файл SCL на объекте – вряд ли он задумывается о том, какие настройки выбраны на коммутаторах. Ведь это задача АСУшников. А АСУшники тоже не думают о релейщиках 🙂 Между тем, большое число GOOSE-сообщений и потоков Sampled Values, которые неконтролируемым образом распространяются по ЛВС, может влиять на быстродействие информационного обмена, к которому предъявляется много претензий. Кстати, об этом также сказано пару слов в новом документе:

NetworkRequirements

Персонал, который осуществляет наладку ПТК АСУ ТП, в качестве входных данных имеет только перечень сигналов для передачи на верхний уровень. А вот какой именно способ передачи сигналов (буферизируемые отчеты, небуферизируемые отчет, периодический опрос) на верхний уровень будет выбран наладчиком зависит от его компетенции.

Можно приводить дополнительные аргументы, но пока данное требование, по мнению редакции ЦПС, выглядит вполне адекватным.

Как формировать файлы SCD?

К сожалению, конфигураторов производителей, которые умеют формировать файлы SCD, мало, а среди отечественных решений – еще меньше. Большинство конфигураторов формируют файлы формата CID (Configured IED Description), который описывает настройки передачи данных в части одного устройства, в отличие от файла SCD.

И здесь на помощь приходят “независимые конфигураторы” (ATLAN, HELINKS, Kalkitech и др.).

Насколько это актуально сегодня?

Актуальность этого вопроса будет возрастать по мере увеличения объема сигналов посредством протоколов стандарта МЭК 61850. Особенно, когда будет увеличиваться количество сигналов, передаваемых таким образом для целей РЗА.

Цифровая подстанция

(close)