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