В восемь утра мастер смены говорит: «Ночью что-то было, сейчас крутится, не помню деталей». Оператор уже на другой линии. Механик ушел домой. В чате цеха три версии одного события. Линия работает, и у руководства возникает соблазн закрыть тему: раз пошло, значит неважно. Инженер АСУ ТП приезжает позже и обнаруживает, что окно инцидента никто не зафиксировал, тренд на экране показывает только последний час, а журнал действий оператора пуст, потому что кнопки «Пуск» и «Стоп» не попадают в audit trail.
Здесь разбираем не полный регламент расследования и не юридическую модель audit trail. Угол узкий: какой минимальный пакет данных собрать за первые 20-40 минут, пока память смены еще жива, но цифровые следы уже начинают стираться перезагрузками, сменой суток и «быстрым пуском». Статья не дублирует общий чек-лист «что нужно после любой аварии» - она про ситуацию, когда утром все забыли, а доказательств почти не осталось.
Сначала зафиксируйте окно инцидента: когда линия встала, когда снова пошла, участок, продукт, кто был на смене. До любых правок и перезагрузок выгрузите тренды процесса и режимов, журнал аварий, SOE (sequence of events), журнал действий оператора. Снимите фото шкафа и местных переключателей, запишите состояние AUTO/MANUAL и bypass. Сверьте время на ПЛК, панели и SCADA.
Минимальный пакет - это не десять PDF на сто страниц. Это восемь артефактов из таблицы ниже, которые позволяют утром спорить о причине, а не о том, было ли что-то вообще. Если собрать только слова смены - это не разбор, а реконструкция по памяти.
Ночная смена решает задачу восстановить выпуск. Дневная приходит на уже работающую линию. Между ними редко есть формальная передача с цифрами. Оператор квитировал аварию, механик переключил селектор, электрик на десять минут снял питание - и каждый сделал правильно с точки зрения «чтобы пошло». Но цепочка событий в головах людей распадается за несколько часов сна.
Параллельно цифровые следы тоже деградируют. Historian с кольцевым буфером перезаписывает ночной интервал к обеду. Панель после перезагрузки показывает только свежий тренд. Журнал SCADA перемешивается с утренними предупреждениями. SOE без синхронизации времени дает порядок событий, которому нельзя верить. Поэтому утренний инженер проигрывает дважды: люди не помнят, а система уже не хранит.
Выход один - собирать минимальный пакет сразу, как только стало известно о ночном инциденте, даже если линия уже работает. Отложить на «после обеда» - значит потерять половину артефактов.
Первый вопрос не «почему упало», а «когда и где». Окно инцидента - это интервал от первого отклонения до устойчивого восстановления плюс запас по краям: обычно 30-60 минут до и 15-30 минут после. Без этих границ тренд открывают «на глаз», выгружают слишком короткий фрагмент и потом ищут причину в пустом месте.
В окно записывают: время остановки и пуска по данным SCADA или ПЛК, номер смены, участок, рецепт или марку, были ли рядом плановые работы, пуск после мойки, смена материала. Эти поля занимают две минуты в сменном журнале, но экономят час при разборе. Если оператор говорит «где-то в два», а в данных первая авария в 01:47, вы сразу знаете, что память сдвинута - и не строите гипотезу на устной версии.
Тренд на HMI и архив historian - разные вещи. Утром на экране видно текущее состояние. Для разбора нужен архив за окно инцидента. В выгрузку попадают не только технологические параметры (температура, давление, расход), но и служебные сигналы: команды пуска и стопа, статусы аварий, режимы AUTO и MANUAL, признаки связи с датчиками, от которых зависели блокировки.
Если historian прореживает данные deadband-ом, короткий ночной сбой на кривой может выглядеть гладко. Поэтому тренд процесса всегда дополняют журналом событий и SOE: они фиксируют момент, когда система зафиксировала отклонение, даже если кривая «не успела нарисовать» проблему. Про настройку трендов и экранов после пуска - в материале «HMI после пуска: какие экраны переделывать по жалобам смены»; здесь важен другой вывод: экран для оператора и архив для разбора должны существовать параллельно.
Журнал аварий отвечает на вопрос «что кричало». SOE и журнал событий - «в каком порядке». Ночной спор часто не о том, что упало, а о причине и следствии: сначала уровень или сначала насос, сначала связь или сначала ручной стоп. Без SOE это спор мнений.
Если время на ПЛК, панели и SCADA расходится хотя бы на несколько секунд, порядок событий переворачивается. Перед интерпретацией SOE стоит проверить синхронизацию - иначе минимальный пакет данных будет внутренне противоречив. Подробнее про метки времени - в статье «Синхронизация времени в АСУ ТП: NTP, PTP, OEE и RCA».
Журнал действий оператора нужен, чтобы понять, трогал ли человек процесс. Без него нельзя отличить «автоматика сама остановила» от «оператор снял разрешение» или «квитировал и запустил в обход». Утром ищут входы и выходы пользователей, квитирования, изменения уставок, переключения режимов, команды с HMI.
Пустой журнал - не доказательство «никто ничего не делал». Это сигнал, что система не записывает нужные действия. Что именно должно писаться в такой журнал, разобрано в «Журнал действий оператора в SCADA: что писать, чтобы потом разобраться». Для утреннего разбора практический вывод: пока журнал неполный, любой вывод о «чистой автоматике» слабый.
Разговор со сменой обязателен, но он не заменяет журнал. Задавайте узкие вопросы - был ли механик, слышали ли шум, переключали ли рецепт - и сразу записывайте ответы с временем беседы. Потом сверяйте каждую фразу с данными SCADA.
Ночью линию часто поднимают во «временном» состоянии: механизм в MANUAL, висит bypass межблокировок, включен force на сигнале, отключена отдельная защита. Утром линия работает, но режим не возвращен в AUTO. Состояние режимов фиксируют в протоколе до возврата в штатный режим.
Фото шкафа кажется мелочью, пока через неделю не выясняется, что ночью переставили автомат или оставили дверцу приоткрытой. Снимают общий вид, индикацию питания и связи, положение местных селекторов, следы вмешательства на клеммах. Если был кратковременный сброс 24 В, фото помогает отличить программную аварию от обесточивания цепи.
Ниже - комплект, который стоит собрать до споров о причине. Его можно вложить в протокол разбора или сменный отчет.
| Артефакт | Что снять | Зачем |
|---|---|---|
| Окно инцидента | время стопа и пуска, участок, продукт, смена | задать границы разбора |
| Тренды процесса | технология, команды, аварии, режимы, связь | увидеть поведение до и после |
| Журнал аварий и событий | аварии, предупреждения, переходы состояний | понять хронологию |
| SOE | события с точными метками времени | отделить причину и следствие |
| Журнал действий оператора | входы, квитирования, уставки, команды | увидеть вмешательство человека |
| Состояние режимов | AUTO/MANUAL, LOCAL, bypass, force | не оставить скрытый обход |
| Фото шкафа и питания | индикация, автоматы, местные переключатели | зафиксировать физическое состояние |
| Время системы | SCADA, ПЛК, панели, historian | не перепутать порядок событий |
Если в пакете есть все восемь позиций, утром можно спорить о причине. Если остались только слова смены - это еще не разбор.
Рабочая последовательность линейная. Убедиться, что линия в безопасном состоянии. Выгрузить тренды и события за окно инцидента. Параллельно взять сменный журнал и коротко опросить смену. Снять фото шкафа и зафиксировать режимы. Проверить время на узлах. Только после этого формулировать гипотезы.
Главная ошибка - начать с перезагрузки сервера или изменения уставки «чтобы больше не падало». Это уничтожает исходные данные. Вторая - считать, что раз линия пошла, причина неважна. Повторяемые ночные остановки почти всегда возвращаются. Третья - полагаться на память: к обеду смена уже не вспомнит, нажимали ли они «Стоп» до или после аварии по уровню.
Не все действия попадают в SCADA. Механик мог переключить местный селектор, электрик снять автомат на десять минут, оператор оставить запись в бумажном журнале смены. Эти источники вторичны по отношению к трендам, но они объясняют странные пробелы: связь пропала в 02:14, потому что в 02:13 сняли питание на время проверки. Утром такую запись легко пропустить, если искать только в цифре.
Полезная привычка - при любом ночном звонке диспетчер или старший смены заполняет короткую форму: время, участок, что сделали для восстановления, кто вмешивался. Две минуты на листе экономят два часа разбора. Для инженера, который только входит в проект, такой маршрут сбора знаний по объекту описан в гайде для инженера АСУ ТП - но на работающем производстве важнее не учебник, а дисциплина смены.
Ночью линию поднимают в MANUAL, включают bypass, оставляют force на датчике «чтобы не падало по плохому quality». Утром линия крутится, а дневная смена не знает, что межблокировка обойдена. Состояние режимов снимают в протокол до возврата в AUTO. Иначе следующая авария будет выглядеть как «автоматика сломалась», хотя корень - вчерашний обход.
Отдельно фиксируют alarm inhibit и отключенные зоны аварий. В журнале событий они могут быть неочевидны, а на экране - без красной полосы. Фото экрана режимов и шкафа закрывает этот пробел.
Если кольцевой буфер затер ночь, ищут данные на других уровнях: экспорт SOE с ПЛК, локальный лог на панели (если не перезагружали), запись видеонаблюдения по времени остановки, весовые или учетные системы, которые пишут независимо от SCADA. Полного восстановления не будет - но иногда хватает одного независимого метода, чтобы подтвердить или опровергнуть версию смены.
Вывод для эксплуатации: минимальный пакет собирают не потому, что «так положено», а потому что архивы ненадежны по умолчанию. Регламент с одной таблицей артефактов дешевле, чем повторный простой из-за неверной гипотезы.
На этапе пуска стоит проверить: пишутся ли команды пуска и стопа в журнал оператора, есть ли выгрузка тренда с панели без инженерной станции, совпадает ли время ПЛК и SCADA, описано ли окно инцидента в сменном регламенте. Это не «лишняя документация», а страховка от сценария «все забыли». Иерархия экранов и аварий для оператора - в материале «HMI оператора: иерархия экранов, аварии, тренды»; здесь акцент на том, что экран для смены и архив для разбора должны существовать параллельно.
Достаточно ли одного журнала аварий?
Нет. Авария говорит, что система зафиксировала проблему. Тренд показывает, как вел себя процесс. SOE - в каком порядке все случилось.
Нужно ли будить интегратора сразу?
Сначала соберите пакет из таблицы. Часто вопрос сужается до конкретного сигнала, режима или питания.
Что делать, если historian уже перезаписал ночь?
Искать экспорт, SOE, сменный журнал, фото, записи диспетчера. И отдельно ставить задачу на нормальный архив для расследований.
Как не забыть собирать пакет в следующий раз?
Вынести таблицу артефактов в сменный регламент и в паспорт объекта АСУ ТП. Тогда «все забыли» перестает быть нормой.
На объектах с панелями и ПЛК, где HMI и архив живут на одном железе, удобно заранее настроить выгрузку трендов и событий с панели оператора - чтобы ночная смена могла сохранить окно инцидента без вызова инженера. Это не заменяет полноценный historian, но спасает минимальный пакет, когда «утром все забыли».