Реализация РФК и сигнала "Аварийное отключение" средствами МЭК 61850"

Каким образом можно реализовать цепочку несоответствия положения выключателя последней оперативной команде управления (в данном контексте успешно выполненной) в канонах 61850, или без внесения изменений в типовые ЛУ не обойтись? Ожидаемый объект данных на выходе – «Выключатель аварийно отключен». Применяется для пуска ТАПВ и сигнализации.
Возможные варианты:
1. Создать локализованный ЛУ, аналог «цепи несоответсвия». На вход ЛУ заводить «Оперативное включение», «Оперативное отключение», «Положение выключателя».
2. Реализовать в одном из типовых ЛУ, к примеру CSWI.
3. Разделить на составляющие «РФК» и «сигнализация несоответствия» и реализовывать в типовых ЛУ.
Иной аспект, это рассмотреть варианты реализации алгоритма «фиксации последней оперативной команды» (успешно выполненной), аналог РФК. Ожидаемый объект данных на выходе – «фиксация команды». В сочетании с «положением выключателя» используется для пуска ТАПВ и сигнализации, при этом алгоритм «несоответствия» предполагается выполнять в принимающих ЛУ.

Также неясно, каким образом лучше осуществлять сброс «фиксации команды». Отдельной командой сброса  или повторной командой управления?

метки:
Денис Сергеенков
Автор: Денис Сергеенков
1
голос
1
ответ
1 ответ

Денис, думаю, наиболее правильным вариантом будет реализация РФК на базе стандартных сигналов узла XCBR, а именно, объекта данных Pos класса DPC.

Класс DPC помимо прочих атрибутов имеет в своём составе атрибут origin типа Originator с FC = ST.

Тип Originator, в свою очередь, состоит из двух атрибутов:

  • orCat (ENUMERATED)
  • orIdent (OCTET STRING64)

Для реализации РФК нам будет интересен именно orCat, для него доступны следующие значения: not-supported | bay-control | station-control | remote-control | automatic-bay | automatic-station | automatic-remote | maintenance | process

В частности, bay-control, station-control и remote-control — это как раз фиксация оперативной команды. А process — это отключение от аналог нашего аварийного отключения (то есть от защит, либо самопроизвольно).

 

ps. Важный нюанс — origin стал иметь строго FC = ST во второй редакции, в первой было FC = ST, CO. У некоторых производителей по первой редакции для него, в частности, устанавливается FC = CO. Из-за этого его не получается репортить или отправлять по GOOSE. Но на новую реализацию это влиять не должно, то есть в своём устройстве вы можете его сделать FC=ST.

pps. Отдельный вопрос ещё в каком узле реализовывать: CSWI или XCBR. В принципе, объект Pos есть в обоих, так что по-хорошему, они должны друг друга “зеркалировать”. Но исходя из предположения, что на один XCBR может воздействовать как CSWI (а то и не один), так и напрямую узлы защиты (отключение от защит), то логичнее, наверно первичным источником делать именно XCBR.Pos.

ppps. Строго говоря, для origin в DPC установлено условное присутствие AC_CO_O, что указывает на то, что он является необязательным при условии, что объект поддерживает управление. Так что для XCBR в таком случае должна быть обязательно задана модель управления отличная от status-only.

Alexey Anoshin
Alexey Anoshin
Вопросов:  0 Ответов:  23

Вам нужно авторизоваться, чтобы оставить ответ .


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

(close)

 

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

(close)

Имя пользователя должно состоять по меньшей мере из 4 символов

Внимательно проверьте адрес электронной почты

Пароль должен состоять по меньшей мере из 6 символов

 

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: