Как найти редкую ошибку в многочасовой записи

Проблема

Ошибка воспроизводится редко и непредсказуемо. Стандартный ответ «запишем всё и посмотрим» упирается в объём: за ночь набегают гигабайты, и глазами их не прочитать. Нужна не запись, а запись с разметкой.

Шаг 1. Настройте условия до прогона

Запись с условиями старта и остановки экономит и место, и время разбора. Если ошибка проявляется после конкретного события на шине, повесьте старт на идентификатор или значение сигнала и включите pre-trigger: предыстория попадёт в запись вместе с самим событием.

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

Шаг 2. Разметьте поток правилами

Цветовое правило на кадры с ошибкой CRC превращает поиск в пролистывание: подсвеченные строки видно на прокрутке. Второе правило — на кадры узла, который вы подозреваете. Правила работают и в онлайне, и при разборе записи, поэтому настраиваются один раз.

Шаг 3. Сузьте поток фильтром

Динамический фильтр применяется во время захвата: приём не останавливается, буфер не сбрасывается. Это важно — фильтр здесь инструмент чтения, а не ограничение записи. Отфильтровали, посмотрели, вернули полный поток.

Шаг 4. Поставьте маркеры и перейдите к сигналам

Нашли первое подсвеченное событие — поставьте маркер. Маркеры глобальные: в Graphics они уже стоят на кривых. Часто причина видна именно там: сигнал ушёл за диапазон за долю секунды до ошибки.

Шаг 5. Соберите доказательство

Выделите интервал между маркерами и выгрузите его — в ASC или BLF для разработчика блока, в CSV для отчёта. При необходимости отправьте этот же участок обратно на шину через replay и повторите ситуацию на стенде.

Чего делать не стоит

• Не читать лог построчно с начала: для редкого события это часы работы.
• Не писать без метаданных: через неделю будет непонятно, какой прогон в какой директории.
• Не фильтровать на этапе записи то, что потом понадобится: отфильтрованное не восстановить.