Надёжность и отказоустойчивость РЗА: отказы, срабатывания

2 месяца назад

4 мин.

Надёжность и отказоустойчивость РЗА: ложные срабатывания, отказы

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

Надёжность и отказоустойчивость в контексте РЗА

Надёжность РЗА — способность выполнять заданные функции в установленных условиях и в требуемый момент времени. Для РЗА это означает:

распознать нужное повреждение/режим;
принять корректное решение (не перепутать внутреннее/внешнее, режим/аварию);
сформировать корректное управляющее воздействие;
обеспечить подтверждаемый результат (включая регистрацию событий).

Отказоустойчивость — способность сохранять требуемую функцию или обеспечивать приемлемый результат при частичных отказах (измерений, питания, связи, исполнительных цепей, внутренних модулей). Отказоустойчивость обеспечивается резервированием и проверяемыми диагностическими механизмами.

Неправильная работа РЗА: классификация для практики

Для эксплуатации удобна классификация «по результату», а не по внутренней причине.

Ложное срабатывание

Ложное срабатывание — защита сработала/выдала команду при отсутствии условий, для которых должна действовать. Типовые формы:

ложное отключение присоединения;
ложный пуск автоматики (например, АПВ/УРОВ) без необходимости;
ложная сигнализация аварийного режима (с ростом нагрузки на персонал и риском неверных действий).

Отказ срабатывания

Отказ срабатывания — условия для действия защиты были, но:

функция не распознала повреждение (не «увидела»);
распознала, но не выдала команду (логика/блокировка/ошибка конфигурации);
выдала, но повреждение не ликвидировано (исполнительная часть).

Неправильное действие

Неправильное действие — защита сработала «не так», как требуется по селективности/объёму отключения/времени. Примеры:

отключила не тот элемент или отключила избыточно;
сработала с неверной выдержкой времени;
не выполнила требуемые блокировки/разрешения (конфликт логики).

«Сработало — не отключило» как отдельный класс дефекта

Выражение «сработало — не отключило» технически означает: защита сформировала внутренний результат (pickup/operate) и/или команду TRIP, но фактического отключения выключателя не произошло или не подтверждено. Это пограничный случай: для алгоритма защиты результат может быть «правильный», а для системы РЗА в целом — отказ ликвидации повреждения.

Цепочка результата: где реально возникают отказы

РЗА как система работает по цепочке:

Измерение (ТТ/ТН) → обработка/логика → выход TRIP → цепи отключения → выключатель → подтверждение/регистрация

Любой разрыв в цепочке меняет тип неправильной работы. В расследованиях важно локализовать разрыв строго по уровням, иначе корректирующие меры будут ошибочными.

Причины неправильной работы по подсистемам

Измерительные цепи (ТТ/ТН и вторичные цепи)

Типовые причины:

насыщение ТТ при внешних КЗ (особенно критично для дифференциальных и направленных функций);
неверные коэффициенты трансформации/полярность/группа соединения;
обрыв/плохой контакт во вторичных цепях, неправильное заземление вторичной цепи;
перегрузка входов, неверный выбор класса точности/нагрузки;
ошибки в цепях ТН (переполюсовка, обрыв фазы, неправильная схема соединения).

Типовые последствия:

ложные срабатывания на внешних КЗ;
отказ чувствительности в минимальных режимах;
неправильное направление/зона.

Логика и конфигурация терминала

Типовые причины:

неверная уставка/единицы/коэффициенты масштабирования;
конфликт блокировок и разрешений (условие распознано, действие запрещено);
ошибки в матрице выходов (функция сработала, но не управляет нужным выходом);
неучтённые режимные положения (ремонтные связи, секционирование);
некорректная версия конфигурации (несоответствие проекту/протоколам).

Типовые последствия:

неправильное действие (селективность нарушена);
отказ действия при реальном повреждении;
ложный пуск автоматики.

Питание DC и внутренняя инфраструктура

Типовые причины:

провалы/потери питания оперативного тока;
деградация аккумуляторов, плохие соединения, отказ DC/DC;
отсутствие/неработоспособность контроля питания;
общий ноль/«плавающий» потенциал, наводки и паразитные цепи.

Типовые последствия:

отказ выдачи команды TRIP (защита распознала, но выход не сработал);
массовые ложные события или перезагрузки терминалов;
потеря регистрации в момент аварии (сложность расследования).

Цепи отключения и выключатель (исполнительный контур)

Типовые причины:

обрыв цепи катушки отключения, отказ катушки, плохой контакт, неправильное включение цепей;
отказ привода/механики выключателя, недостаточное давление/энергия привода;
отсутствие подтверждения положения (52a/52b) или некорректные контакты положения;
неверная логика УРОВ или отсутствие условий его пуска.

Типовые последствия:

«сработало — не отключило»;
затяжные КЗ и переход к резервному отключению (часто с большим объёмом отключения).

Каналы связи и синхронизация времени (если применимо)

Типовые причины:

потеря/ухудшение каналов для телеускорения/дифф. защит/межтерминальных логик;
рассинхронизация времени, разная точность SOE;
несогласованность конфигураций на концах (для end-to-end схем).

Типовые последствия:

отказ или неправильное действие функций, завязанных на связь;
невозможность корректно сопоставить события при расследовании.

Показатели надёжности, применимые в эксплуатации

MTTR (Mean Time To Repair / среднее время восстановления) — практический показатель ремонтопригодности: сколько в среднем занимает восстановление работоспособности после выявленного отказа. Для РЗА MTTR зависит от:

доступности информации (SOE, осциллограммы, самодиагностика);
модульности оборудования (замена терминала/модуля);
зрелости процедур (шаблоны проверок, контроль версий, запасные части).

MTBF (среднее время между отказами) полезен как статистическая оценка, но для РЗА сам по себе недостаточен: важнее не «как редко ломается», а «как система ведёт себя при повреждении и как быстро восстанавливается после выявленного дефекта». Для критичных объектов приоритет часто у MTTR и у способности предотвращать неправильные действия.

Практический KPI для службы РЗА

Для эксплуатационной отчётности обычно достаточно:

число ложных срабатываний (по функциям/объектам) и их доля;
число отказов срабатывания/отказов отключения;
доля случаев «сработало — не отключило» и среднее время восстановления (MTTR);
количество изменений конфигурации и доля изменений без полного комплекта подтверждающих документов (как риск-фактор).

Методика анализа причин: как не ошибиться с выводами

Эффективный анализ строится от результата к причине, по цепочке уровней.

Шаг 1 — квалификация результата

Определите тип события:

ложное срабатывание;
отказ срабатывания;
неправильное действие;
«сработало — не отключило».

Шаг 2 — локализация разрыва

Ответьте последовательно:

было ли условие (по осциллограмме/режиму/моделированию)?
было ли срабатывание функции (pickup/operate)?
было ли действие (TRIP/команда/пуск)?
было ли отключение (положение выключателя + электрический результат)?
сработало ли резервирование (в т.ч. УРОВ) и с какими временами?

Шаг 3 — проверка “треугольника причин”

Для большинства инцидентов причины попадают в один из трёх блоков:

измерения (ТТ/ТН/вторичка);
конфигурация/логика/уставки;
исполнительная часть (DC/цепи TRIP/выключатель).
Если причина не укладывается — проверяйте условия испытаний/моделирования и корректность синхронизации времени.

Шаг 4 — корректирующие меры, привязанные к уровню

Если проблема в измерениях — меры по ТТ/ТН, вторичке, заземлению, проверкам полярности/нагрузки.
Если проблема в логике — контроль версий, матрица выходов, ревизия блокировок, повторные функциональные испытания.
Если проблема в исполнительной части — контроль цепей отключения, питание DC, диагностика выключателя, проверка УРОВ.

Типовые ошибки при построении и сопровождении надёжности РЗА

Смешивают “работу функции” и “работу системы”

Отчёт «защита сработала» без подтверждения отключения не закрывает риск.

Не ведут управление конфигурацией

После нескольких изменений теряется соответствие проекту и невозможно воспроизвести условия инцидента.

Опираются на SCADA вместо SOE терминала

Недостаточная точность времени и неполнота событий ухудшают расследование и увеличивают MTTR.

Не проверяют цепи отключения как часть РЗА

TRIP-цепь и выключатель — обязательная часть доказательства работоспособности.

Устранение симптома вместо причины

Поднятие уставок «чтобы не отключало» может убрать ложное срабатывание и одновременно создать отказ срабатывания.

Минимальные требования к протоколам и учёту для надёжности

классификация каждого инцидента по типу неправильной работы;
наличие подтверждений по уровням: срабатывание → действие → отключение;
фиксация времён t_trip, t_breaker, t_clearing;
ссылка на версию конфигурации/карты уставок и дату изменений;
вывод по причине (измерения / логика / исполнительная часть) и корректирующее мероприятие.