Опрос устройства по протоколу МЭК 60870-5-103

[Shkuda]

Добрый день.
Может кто-то поделится опытом опроса микропроцессорной защиты (например Micom P116 или P139 - у меня сейчас такие) контроллером по протоколу МЭК-103. Контроллер не указываю, т.к. в данном контексте это не принципиально. Интересует именно выдача определенных сигналов защитой по 103 протоколу. Это сигналы сработки ступеней защит: например trip tI>>. Сигналы сработки защит приходят только спорадически и по переднему фронту сигнала, сигнала спада в 0 нет, общим опросом они тоже не передаются.
Вот выдержка по сигналу из руководства к защите:
50/51: Trip tI>>>: ASDU<2>;FUN<162>;INF <141>; COT<1,7>,<ADDR>,*
Звездочка означает следующее:
In the list below, events only generated on rising edge will be tagged with a ‘*’ (В приведенном ниже списке события, генерируемые только по переднему фронту, будут помечены знаком "*".
Возник вопрос: данный сигнал приходит, устанавливается в 1 и висит в таком состоянии. Вопрос каким образом можно его сбросить его в 0, чтобы видеть следующие сработки? При сбросе индикации защиты с панели или дистанционно данный сигнал остается все равно висеть. Может кто-то проконсультирует. Буду благодарен за любую информацию.

[asuprog]

Не знаком с протоколом. Думаю, что если доступа к сигналу (ячейке где эта 1) с правами записи нет, то и ни как. Если есть какой доступ, то программировать в ПЛК принудительный сброс при регистрации.
Написал очевидную какую то вещь )
Но всегда непонятно, что там в голове и на столе у топикстартера на самом деле ;)

[petr2off]

Не совсем понял, а при чем здесь протокол. Тот же 103 например может в РДУ через шлюз передаваться уже по 104, и проблема тем не менее остается. Давайте по полочкам разложим. Имеется факт срабатывания защиты, который Вы видите по 103 протоколу (хотя еще раз отмечаю - по какому протоколу Вы видите защиту - не принципиально), и сигнал фиксируется (заметим - что эта логика обработки сигнала контроллером). И вопрос на самом деле - к этой самой логике. Вариантов бывает несколько:
1) Стандартный, на АРМе выдается звуковой сигнал и индикация (обычно это видно в соответствующем журнале, где он и регистрируется), после чего он квитируется оператором. Возможны нюансы.
2) При снятии условий срабатывания защиты, сигнал снимается контроллером, но факт срабатывания в журнале остается.
3) Сигнал срабатывания "растягивается" по времени, что бы внешняя система (например в РДУ) его успела зарегистрировать.
Ну наверно еще можно придумать варианты обработки.
В любом случае, все начинается в контроллере (терминале защиты). И сам сигнал не обнуляется (во всяком случае я такого не видел). Даже квитирование сигнала сработки - это не обнуление его, а фиксация того факта, что он принят оператором. И поэтому гудеть и мигать не надо. Иногда, правда, он блокируется. Но это другая история.

[asuprog]

И сам сигнал не обнуляется

А мне так проблема увиделась - защита отработала, подала сигнал об этом. Но система еще работает. И защита может сработать еще раз. Только мы ее не увидим.
Как на самом деле, как всегда не ясно

[Shkuda]

Доброго дня.
Контроллер телемеханики (специализированный для телемеханики - ЭНКС-3м производства Энергосервис, город Архангельск) сейчас настроен как ретранслятор сигнала с защиты на верхний уровень. Т.е. сигнал снимается контроллером по 103 протоколу, далее при спорадическом его изменении (с 0 на 1) реализуется выдача на верхний уровень по 104 протоколу. Как-то воздействовать на него в обратном направлении (запись) в устройстве защиты нельзя.
По поводу вариантов озвученных чуть выше:
1. Это функционирует нормально (ручное квитирование каждого отдельного сигнала сработки ступеней защиты, т.к. выдача команды на терминал (защита) с лицевой панели или дистанционно контроллером снимает только сигнализацию с защиты - LED-ы. LED-ы по 103 протоколу снять нельзя, только функции пуска и сработки защит).
2. Влиять контроллером на сигнал выдачи на верхний уровень сейчас нельзя, он настроен как ретранслятор (но буду наверное пробовать какую-то логику)
3. Сигнал регистрируется нормально, поэтому это не актуально.
Напрягает сейчас именно то, что при тестировании системы релейщиками я вижу только первую сработку. Далее они сбрасывают защиту, дают следующую - я ее уже не вижу, вижу только первую. Решение данной задачи, наверное, все-таки в организации в контроллере сигнала сброса данной сработки, т.е. принудительная выдача изменения с 1 на 0 по какому-либо условию.