Авария была ночью: Какие данные нужны утром, чтобы не гадать по памяти

Телефон в семь утра: «Линия встала ночью, сейчас крутится, но вчерашний разбор уже никто не помнит». На объекте это обычная картина. Ночная смена устала, дневная еще не пришла, механик что-то подкрутил у агрегата, оператор квитировал аварию и пошел дальше, а инженер АСУ ТП узнает о проблеме только утром - когда журнал уже перемешан с новыми событиями, тренды могут быть перезаписаны, а в чате цеха остались три разные версии «что было первым».

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

Здесь не про audit trail как юридическую модель и не про красивый отчет для аудита. Угол практический: что собрать за первые 30-60 минут после звонка, чтобы не гадать по памяти смены и не начинать наладку с перезагрузки «на всякий случай».

Короткий ответ

Утром после ночной аварии сначала фиксируют окно инцидента - когда линия встала, когда снова пошла, какой участок и продукт были в работе. Затем, до любых правок в проекте и до перезагрузки серверов, снимают тренды процесса, журнал аварий и событий, журнал действий оператора, сменный журнал, состояние режимов, фото шкафа и питания, время на SCADA, ПЛК и панелях, актуальный бэкап проекта и паспорт объекта.

Порядок простой: не трогать настройки, пока не выгружены тренды и события; не спорить со сменой, пока слова не сверены с журналом SCADA; не менять логику, пока не понятна ревизия и не проверен бэкап. Только после этого имеет смысл идти в шкаф, к ПЛК и в программу.

Почему утром не хватает одной версии событий

Ночью информация распадается на несколько потоков, которые редко сходятся сами. Оператор видит экран и квитирует аварии. Механик видит механику и иногда трогает местные кнопки. SCADA пишет события - если журнал настроен. Электрик может на время снять питание с цепи. Подрядчик подключить ноутбук. Каждый поток правдив в своей части, но вместе они не складываются в одну линию без подготовки.

Через несколько часов остается не факт, а интерпретация. «Сначала упал уровень». «Нет, сначала отвалился датчик». «Насос остановили вручную, потому что шумел». «Автоматика сама ушла в аварию». Каждая фраза может быть правдой - но только частью правды. Без тренда и sequence of events (SOE) это спор мнений, а не разбор.

Поэтому утренний инцидент начинают не с вопроса «кто виноват», а с вопроса «какие данные еще можно сохранить, пока их не затерли». Перезапуск сервера, очистка журнала, «быстрый пуск» без записи, подтяжка клемм без фиксации состояния - все это уничтожает улики быстрее, чем кажется.

Разговор со сменой: нужен, но не вместо данных

Разговор со сменой обязателен. Без него непонятен контекст: был ли пуск, переключение рецепта, мойка, плановая остановка, работал ли рядом механик, слышали ли необычный шум, когда линия снова пошла - сама или после действия человека. Но этот разговор не заменяет выгрузку трендов и событий.

Полезно задавать узкие вопросы и сразу записывать ответы в сменный журнал или протокол разбора - с подписью и временем беседы. Потом каждую фразу сверяют с журналом SCADA. Память смены ценна для контекста, но плохо работает как единственный источник истины. Бывает, что оператор честно описывает последовательность, а в данных видно другое - не потому что он врет, а потому что ночью многое сливается в одно воспоминание.

Тренды и журнал событий: что снимать первым

Тренд - главный способ увидеть, что процесс делал до, во время и после аварии. Утром важно не «открыть экран сейчас», а выгрузить архив за окно инцидента с запасом по краям: обычно полчаса-час до первого события и 15-30 минут после восстановления. В выгрузку попадают не только технологические параметры, но и команды пуска и стопа, аварийные статусы, режимы AUTO и MANUAL, признаки связи с датчиками, от которых зависела блокировка.

Если historian хранит данные с прореживанием, короткий инцидент на тренде может выглядеть «гладко», хотя внутри были колебания. Поэтому рядом с трендом процесса всегда снимают журнал событий: он фиксирует момент, когда система зафиксировала отклонение, даже если кривая визуально не успела «нарисовать» проблему.

Журнал аварий отвечает на вопрос «что кричало». SOE и журнал событий - на вопрос «в каком порядке это случилось». Для ночной аварии это критично: спор часто не о том, что упало, а о том, что было причиной, а что следствием. Если время на ПЛК, панели и SCADA расходится, порядок событий может стать фикцией. Разница даже в несколько секунд на ночном инциденте переворачивает цепочку «сначала - потом». Перед спором о причине стоит проверить синхронизацию времени на объекте. Подробнее про порядок событий и точность меток - в материале «SOE в промышленности: точность времени и порядок событий».

Журнал действий оператора и сменный контур

Журнал действий оператора нужен не для отчета, а чтобы понять, вмешивался ли человек в процесс. Без него нельзя отличить «автоматика сама остановила» от «оператор снял разрешение» или «квитировал и запустил в обход». Утром ищут входы и выходы пользователей, квитирования, изменения уставок, переключения режимов, команды пуска и стопа с HMI.

Если в журнале пусто, это не значит, что никто ничего не делал. Это значит, что система не записывает нужные действия - и вы снова остаетесь с памятью смены. Что именно должно писаться в такой журнал, разобрано в статье «Журнал действий оператора в SCADA: что писать, чтобы потом разобраться». Для утреннего разбора практический вывод один: пока журнал неполный, любой вывод о «чистой автоматике» слабый.

Не все действия попадают в SCADA. Механик мог переключить местный селектор, электрик снять автомат на десять минут, оператор оставить запись в бумажном журнале смены. Сменный журнал, наряд, запись диспетчера, листок на дверце шкафа - вторичные источники. Их собирают, но не ставят выше трендов и событий. Зато они часто объясняют странный разрыв в данных: связь пропала в 02:14, потому что в 02:13 сняли питание на время проверки.

Ручной режим, шкаф и питание

Ночью люди делают то, что помогает быстро восстановить выпуск. Иногда это допустимо по регламенту, иногда - нет. Утром важно понять, не остался ли объект в «временном» состоянии: механизм в MANUAL или LOCAL, включен bypass межблокировок, висит force на сигнале, отключена отдельная защита или alarm inhibit. Очень частая картина: линия работает, но в ручном режиме, а дневная смена узнает об этом только при следующей аварии. Состояние режимов фиксируют в протоколе разбора сразу, до возврата в AUTO.

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

Бэкап, ревизия и паспорт объекта

Утром часто хочется «чуть подправить логику», чтобы больше не падало. Это рискованно, пока не понятно, что именно произошло. До любых изменений нужно знать, какая ревизия проекта сейчас загружена в ПЛК и SCADA, есть ли архив последней рабочей версии, не работал ли ночью кто-то с инженерной станции. Если ревизия неизвестна, сначала снимают текущий проект и сверяют с паспортом объекта. В статье «Резервное копирование и восстановление ПЛК/SCADA: как проверить, что бэкап реально работает» мы отдельно разбирали, почему ценен не сам архив, а проверенное восстановление. На утреннем разборе это простое правило: не лечить ночную аварию экспериментом без точки возврата.

Даже идеальный тренд не поможет, если инженер не знает, какой датчик за каким тегом стоит, какая уставка была согласована и какая ревизия схемы актуальна. Таблица сигналов, as-built шкафа, карта режимов и блокировок, регламенты по авариям участка, записи о последних изменениях - это слой, который должен жить в паспорте объекта АСУ ТП после пуска. Если паспорта нет, утренний разбор почти всегда длиннее: половина времени уходит на восстановление контекста, который давно должен был лежать в папке объекта.

Десять артефактов, без которых разбор превращается в угадывание

Ниже - минимальный комплект, который стоит собрать до споров о причине. Его можно вложить в протокол разбора или в сменный отчет.

Если собраны все десять позиций, утром можно спорить уже о причине, а не о том, было ли что-то вообще. Если остались только слова смены и текущий экран - это еще не разбор, а реконструкция по памяти.

Первый час: без суеты и без перезагрузки «для очистки»

Рабочая последовательность обычно линейная. Сначала убеждаются, что линия в безопасном состоянии и можно собирать данные. Потом выгружают тренды и события. Параллельно берут сменный журнал и коротко опрашивают смену. Затем снимают фото шкафа и фиксируют режимы. После этого проверяют время на узлах, ревизию проекта и наличие бэкапа. Только затем формулируют гипотезы.

Главная ошибка - начать с перезагрузки или с изменения уставки «чтобы больше не падало». Это уничтожает исходные данные и делает повтор ночной ситуации невозможным. Вторая по частоте - начать с разговора, не выгрузив тренды: версия смены становится единственной версией, и она может быть неверной. Третья - считать, что раз линия пошла, причина неважна. Повторяемые ночные остановки почти всегда возвращаются.

Вопросы при работе

Достаточно ли журнала аварий без трендов?

Нет. Авария говорит, что система зафиксировала проблему. Тренд показывает, как вел себя процесс до этого.

Нужно ли будить интегратора сразу?

Сначала соберите артефакты из таблицы выше. Часто после этого вопрос сужается до конкретного сигнала, режима или питания.

Что делать, если historian уже перезаписал старые данные?

Искать экспорт, SOE, сменный журнал, фото, записи диспетчера. И отдельно ставить задачу на нормальный архив для расследований.

Итог

Ночная авария утром проверяет не только автоматику, но и зрелость эксплуатации. Если на объекте есть тренды, события, журнал действий, сменный контур, фото, дисциплина времени, бэкап и паспорт - разбор занимает часы. Если этого нет - дни, и он превращается в спор воспоминаний.

Большинство нужных данных на типовом объекте уже существует. Плохая новость в том, что их редко собирают сразу. Память смены нужна. Но утром выигрывает тот, у кого есть тренд, события и журнал - а не только рассказ «было что-то ночью».