На цифровой подстанции с обширным применением GOOSE-коммуникаций персонал столкнулся с периодическим появлением сигналов «Неисправность» и «Ошибка входящих GOOSE» от ряда устройств РЗА и АСУ ТП. Подобные эпизоды возникали несколько раз в день: система внезапно переходила в состояние неисправности, после чего самостоятельно возвращалась в нормальный режим работы. При этом причина происходящего оставалась неочевидной.
Внешне система продолжала работать штатно:
- отключений оборудования не происходило;
- аварий не фиксировалось;
- связь с устройствами не терялась;
- диагностика ИЭУ не показывала отказов.
Именно такие «плавающие» проблемы считаются одними из самых сложных для расследования на цифровых подстанциях. Дополнительную сложность создавало отсутствие на подстанции регистратора событий высокоавтоматизированной подстанции (РС ВАПС), который мог бы автоматически зафиксировать и классифицировать нештатные события в локальной сети объекта.
Единственным источником информации оказался pcap-файл длительностью около 11 минут, записанный специалистами при подключении к ЛВС подстанции. По этому дампу и нужно было понять, что происходит с устройствами РЗА и АСУ ТП.
Почему Wireshark недостаточно
Первичный анализ специалисты подстанции начали выполнять в Wireshark. Это самый популярный инструмент для работы с сетевым трафиком, и он отлично подходит для детального просмотра отдельных пакетов. Однако в подобных инцидентах проблема заключается не в отсутствии доступа к данным, а в масштабе и сложности самого анализа.
В распоряжении инженеров оказался pcap-файл почти со 186 тысячами GOOSE-пакетов и более чем 200 активными GOOSE-источниками. При таком объёме трафика специалист видит непрерывный поток сообщений, внутри которого необходимо найти кратковременные отклонения.
Сложность заключается ещё и в том, что для ручного анализа инженер должен заранее понимать, что именно и где надо искать: пропажу GOOSE в сети или изменение качества сигналов, задержки GOOSE или проблему синхронизации времени на устройствах и т. д. В результате поиск причины превращается в проверку десятков гипотез среди тысяч пакетов.
Например, чтобы обнаружить кратковременное превышение параметра timeAllowedToLive (TATL), необходимо вручную анализировать интервалы между соседними пакетами каждого GOOSE-сообщения и сравнивать их со значением TATL, переданным в предыдущем сообщении. При таком объёме трафика подобная проверка может занимать часы, особенно если нарушение длится всего несколько десятков миллисекунд.
Не менее сложен и анализ качества сигналов GOOSE. В одной публикации могут передаваться десятки сигналов, а изменение даже одного бита качества — например переход validity в состояние Invalid — скрыто внутри структуры GOOSE, и визуально обнаружить его крайне сложно.
Теоретически все эти проблемы можно выявить средствами Wireshark. Практически — подобный анализ требует много часов ручной работы и при этом не гарантирует, что причина инцидента действительно будет найдена.
Решение: автоматический анализ pcap в ПО Теквел Магия
Полученный pcap-файл был загружен в ПО Теквел Магия — анализ занял несколько минут. После обработки программа автоматически сформировала Excel-отчёт, в котором были собраны все обнаруженные проблемные устройства, события и нарушения с указанием уровня критичности.
При этом каждое событие привязывается к конкретному номеру пакета в pcap-файле. Инженер при необходимости может открыть нужное место в Wireshark, уже понимая, что именно произошло. Дополнительно, если есть исполнительный SCD-файл, соответствующий конфигурации устройств, — вместо порядкового номера сигнала указывается сигнал из модели и его описание, что значительно облегчает понимание ситуации.
Главное — инженерам больше не требовалось вручную искать проблему среди тысяч пакетов. Вместо большого pcap-файла они получили понятную картину происходящего на объекте.
Из сетевого трафика — в готовое техническое заключение
Результатом работы Теквел Магия становится полноценный отчёт внеочередной проверки. Отчёт формируется в формате Excel и построен по принципу последовательного расследования — от общей оценки состояния оборудования и ЛВС до детального анализа конкретных событий и сигналов.
На первой странице — «РЕЗЮМЕ». Здесь отображается общая информация о файле: время записи, уникальный код файла для исключения возможности корректировки pcap, количество GOOSE- и SV-пакетов и публикаций, а также итоговое заключение по результатам анализа — все обнаруженные проблемные устройства, события и нарушения с указанием уровня критичности.
Уже на этом этапе специалист видит, были ли обнаружены критические нарушения, сколько GOOSE-публикаций находятся в аварийном состоянии, сколько требуют внимания и какие проблемы встречаются чаще всего. Для быстрого поиска причин дополнительно формируется список наиболее проблемных устройств-источников и перечень основных типов нарушений. Фактически «РЕЗЮМЕ» позволяет за несколько секунд ответить на вопрос: есть ли в сети проблема и где её искать в первую очередь.
Следующий этап расследования — «Состояния». На нём отображается состояние всех публикаций на момент начала записи трафика. Практика показывает, что многие проблемы существуют ещё до того, как персонал начинает расследование.
После оценки начального состояния инженер переходит к разделу «События», который является основным инструментом расследования. Здесь в хронологическом порядке отображаются все изменения в данных и их категоризация по критичности. Для каждого события указываются:
- источник (LD/CB);
- srcMAC устройства;
- сигнал;
- описание нарушения;
- категория критичности по влиянию на работу систем РЗА и АСУ ТП;
- номер пакета;
- точное время возникновения.
Благодаря этому специалист может увидеть сам факт нарушения:
…и проследить последовательность событий, которая привела к возникновению проблемы на объекте:
Следующий раздел — «Счётчик изменений». Он показывает, какие сигналы изменялись чаще всего за время записи. Для каждого сигнала рассчитывается количество изменений и средняя частота их возникновения в динамическом окне в 1 секунду. Такой анализ позволяет быстро обнаруживать немотивированное и/или излишне частое изменение состояния сигналов, некорректно настроенную апертуру и другие процессы, способные создавать повышенную нагрузку на оборудование ЛВС и сами устройства РЗА и АСУ ТП.
В рассматриваемом примере именно этот раздел позволил увидеть сигналы, которые изменялись 600–800 раз за 11 минут записи и фактически формировали основной объём событийного трафика.
Последний лист — «Справочник». Он содержит описание всех контролируемых критериев анализа, кодов событий, правил классификации нарушений и пояснения, чем грозит то или иное обнаруженное нарушение. Благодаря этому отчёт остаётся понятным не только специалисту, который выполнял анализ, но и коллегам, производителям оборудования или представителям эксплуатирующей организации.
Таким образом, Теквел Магия превращает pcap-файл в структурированное расследование инцидента. Инженер получает общую картину происходящего, список проблемных устройств, полную хронологию событий и возможность перейти к конкретному пакету в исходном дампе трафика при необходимости дополнительной проверки.
Что обнаружилось на объекте
Критические превышения TATL
Основная причина циклических «Неисправностей» оказалась связана с нарушением параметра timeAllowedToLive (TATL). Для одного из GOOSE-потоков система зафиксировала регулярные превышения допустимого интервала между пакетами: при TATL = 20 мс реальные интервалы периодически достигали 33 мс. В одном из эпизодов произошло сразу пять последовательных нарушений подряд — для устройств-приёмников это означало остановку получения информации от устройства-источника.
Полное исчезновение GOOSE-сообщения
Дополнительно Теквел Магия обнаружила событие, когда один из GOOSE-потоков полностью исчез из сети почти на две минуты:
- отсутствие GOOSE — более 107 секунд;
- допустимый интервал по TATL — 4816 мс.
В ручном просмотре Wireshark такой эпизод практически невозможно заметить среди сотен активных публикаций.
Сбои в работе счётчика GOOSE stNum
Система также выявила некорректную работу счётчика состояния stNum:
- данные в GOOSE-сообщении изменились, но stNum не увеличился;
- затем stNum увеличился уже без изменения данных.
Это признак нештатного поведения GOOSE-публикации, способный приводить к неправильной интерпретации событий принимающими устройствами.
Проблемы качества данных
В нескольких публикациях был обнаружен признак validity = Invalid. Причём часть нарушений присутствовала уже в начальном состоянии записи — то есть проблема существовала ещё до момента, который специалисты считали началом внеочередной проверки.
Выводы
«Плавающая» неисправность, которую сложно локализовать привычными средствами, оказалась не одной ошибкой, а целым набором взаимосвязанных нарушений в GOOSE-трафике: периодические превышения TATL, кратковременные и длительные пропадания публикаций, сбои счётчика stNum и ухудшение качества сигналов. Каждое из этих нарушений по отдельности коротко по времени и легко теряется в общем потоке — и именно поэтому ручной анализ в Wireshark не давал результата.
С использованием ПО Теквел Магия превращение 11-минутного дампа в структурированный отчёт заняло пару минут вместо многих часов ручной работы — и при этом дало результат, который ручной анализ не гарантировал.
Отдельно стоит подчеркнуть системный урок: отсутствие на объекте постоянного мониторинга (РС ВАПС) превращает любой инцидент в разовое «полевое» расследование по случайно записанному дампу. Там, где такая система установлена, события вроде превышений TATL, пропаданий GOOSE и сбоев stNum фиксируются и классифицируются непрерывно — и большинство «плавающих» неисправностей перестаёт быть загадкой. Но даже когда непрерывного мониторинга нет, ПО Теквел Магия позволяет провести полноценное расследование постфактум: загрузить pcap, получить техническое заключение и принять обоснованное инженерное решение.
Реальная магия — но полностью инженерная.