Самый неприятный разбор смены начинается не с аварии, а с фразы: «да вроде никто ничего не нажимал». На экране было красное сообщение, насос ушел в ручной режим, уставка почему-то изменилась, технолог говорит одно, оператор другое, наладчик вспоминает, что «кажется, проверял тег». Через час обсуждения становится ясно: данных о процессе много, а ответа на простой вопрос нет. Кто сделал действие, с какого места, в какой момент и что было до этого?
Журнал действий оператора нужен не для того, чтобы искать виноватого после каждой кнопки. Нормальный журнал нужен, чтобы не восстанавливать производство по памяти. Память смены полезна, но она устает, путает порядок событий и защищается от неприятных выводов. Запись в SCADA должна спокойно отвечать на факты: пользователь вошел, подтвердил аварию, изменил уставку, включил ручной режим, применил force на наладке, выгрузил журнал. Если этого следа нет, расследование быстро превращается в спор характеров.
Эта статья не про настройку конкретной SCADA и не про MasterSCADA по кнопкам меню. Речь о регламенте: какие действия нужно фиксировать, чем событие отличается от аварии, почему квитирование не равно устранению причины и какие поля должны быть в записи, чтобы через месяц по журналу можно было восстановить хронологию.
Событие, авария и действие оператора - это разные вещи
В эксплуатации часто все называют «авариями»: мотор остановился, связь пропала, оператор нажал сброс, наладчик вошел в сервис, технолог поменял уставку. Для экрана это может быть один общий список, но для разбора это разные классы фактов.
Авария говорит, что технологический или технический параметр вышел за допустимую границу: перегрев, отсутствие связи, превышение давления, отказ датчика, сработала защита. У аварии есть состояние: активна, квитирована, ушла, возвращалась повторно. Она отвечает на вопрос «что произошло с объектом».
Событие шире. Это может быть вход пользователя, запуск сменного отчета, потеря связи, переход оборудования в режим, экспорт архива. Событие отвечает на вопрос «что зафиксировала система».
Действие оператора - отдельная категория. Это то, что сделал человек через HMI или SCADA: нажал пуск, подтвердил аварию, изменил уставку, перевел агрегат в ручной режим, снял блокировку, вошел под своей учетной записью. Оно отвечает на вопрос «кто сделал действие и с каким результатом».
Если эти три сущности смешаны в один поток без полей, журнал становится шумом. Оператор видит сотню строк, инженер не может отделить автоматическое событие от ручной команды, а комиссия по разбору инцидента просит скриншоты и переписку. Поэтому хорошее журналирование начинается не с объема, а с смысла: запись должна помогать восстановить причинно-следственную цепочку.
Почему «кто нажал» нельзя восстанавливать по памяти
На спокойном участке кажется, что все и так понятно. Смена маленькая, люди работают давно, шкафы знакомые, у каждого свой почерк. Но как только появляется ночная авария, подрядчик на удаленке, наладка после ремонта или конфликт между сменами, устная картина рассыпается.
Оператор мог нажать квитирование, потому что сирена уже мешала работать, а причина еще не устранена. Наладчик мог временно перевести насос в ручной режим и не вернуть автомат. Технолог мог поднять уставку «на пять минут», чтобы пройти нестабильный режим. Администратор мог экспортировать журнал не за тот период. В каждом случае человек мог действовать разумно в своей ситуации, но без записи система теряет контекст.
Хороший журнал не отменяет доверие к людям. Он снимает лишнее напряжение с разговора. Вместо «ты точно не менял?» появляется «в 02:14 пользователь такой-то с рабочего места такого-то изменил уставку с 68 до 72, причина не указана, через три минуты пришла авария по температуре». Это уже предметный разбор, а не допрос.
Вход пользователя: общая учетная запись ломает весь смысл
Журнал действий оператора начинается с входа. Если на объекте один пароль operator на всю смену, журнал покажет только роль, но не человека или хотя бы сменную группу. Иногда для малых объектов это сознательный компромисс, но тогда нельзя потом требовать точного ответа «кто нажал». Система физически этого не знает.
Лучше, когда учетная запись соответствует человеку, роли или хотя бы сменной бригаде, а права разделены по задачам. Оператор видит свой участок и выполняет штатные команды. Наладчик заходит в сервис, где его действия отличаются от обычной смены. Администратор управляет пользователями, экспортом и настройками, но не ведет ежедневный процесс под админской учеткой.
Про разумное разделение ролей на панели уже есть отдельный материал «Роли и доступ на панели». Для журнала отсюда важен простой вывод: если роли смешаны, журнал тоже будет смешан. А если все работают под одной учеткой, audit trail превращается в красивую таблицу без главного поля.
Квитирование: подтвердил сообщение, но не исправил причину
Квитирование часто неправильно воспринимают как «авария закрыта». На самом деле ack обычно означает другое: оператор увидел сообщение и взял его в работу. Причина может сохраняться, агрегат может оставаться остановленным, защита может быть активной, но сирена или мигающий статус уже подтверждены.
Поэтому в журнале квитирование нужно писать отдельно от исчезновения аварии. Хорошая запись отвечает на три вопроса: кто подтвердил, какую именно аварию, в каком состоянии она была. Если журнал хранит только строку «авария квитирована», без пользователя и объекта, для расследования она почти бесполезна.
Особенно важно фиксировать массовое квитирование. Кнопка «подтвердить все» удобна при alarm flood, но при разборе она может скрыть детали: оператор действительно видел каждую аварию или просто убрал шум с экрана? Это не значит, что массовое квитирование всегда запрещено. Это значит, что оно должно оставлять след как отдельное действие, а не растворяться в десятке одинаковых строк.
Изменение уставки: старое и новое значение обязательны
Уставка без истории - один из самых частых источников долгих споров. «Вчера линия работала нормально», «сегодня датчик тот же», «программа не менялась», а потом выясняется, что кто-то аккуратно поправил порог, задержку, лимит скорости или температуру. Может быть, по делу. Может быть, временно. Может быть, ошибся разрядом. Но если журнал не хранит старое и новое значение, расследование начинается с догадок.
Запись изменения уставки должна фиксировать не только факт записи, но и контекст: какой тег или параметр изменен, какое было значение, какое стало, кто изменил, откуда, в каком режиме был агрегат. Для критичных уставок полезно добавить причину или номер заявки, но даже без этого старое/новое значение уже спасает разбор.
Не стоит превращать журнал в поток каждого обновления слайдера при перетаскивании мышкой. Фиксировать нужно примененное значение: то, что реально записано в контроллер, SCADA или рецепт. Иначе журнал будет большим, а смысла в нем меньше.
Ручной режим и наладка: не штатный фон, а состояние с владельцем
Ручной режим сам по себе не нарушение. На объекте есть обслуживание, промывка, проверка привода, вывод оборудования после ремонта. Проблема начинается, когда ручной режим становится невидимым фоном: насос уже давно не в автомате, но журнал этого не показывает, на HMI маленькая подпись, смена передала устно, а причина остановки потом ищется в программе.
Переход Auto/Manual/Service нужно писать как действие с пользователем и объектом. Если режим включен из SCADA, запись должна отличаться от локального ключа или аппаратного переключателя, если такая информация доступна. Если режим сервисный, полезно фиксировать ожидаемый срок или хотя бы основание: наладка, ремонт, проверка, обход.
Force и симуляция требуют еще более строгого отношения. Принудительное значение может быть отличным инструментом наладки, но в эксплуатации оно опасно именно тем, что система начинает показывать не то, что происходит физически. В статье «Отладка HMI на объекте» мы уже разбирали, почему force нельзя оставлять без следа. В журнале должны быть включение force, снятие force, тег, значение, пользователь и причина. Если есть только факт «наладчик был в системе», этого мало.
Экспорт журнала тоже должен попадать в журнал
На первый взгляд экспорт - безобидная операция. Человек выгрузил CSV или PDF, чтобы отправить инженеру, приложить к акту, разобрать инцидент. Но если журнал может содержать данные объекта, пользователей, технологические режимы и признаки аварий, выгрузка сама становится значимым действием.
Минимум стоит фиксировать: кто экспортировал, за какой период, какой тип журнала, с какого рабочего места. Для объектов с требованиями ИБ добавляют путь выгрузки, контрольную сумму файла, основание запроса. Не потому, что каждый экспорт подозрителен, а потому, что журнал должен сохранять цепочку владения данными. Иначе через месяц у всех на руках разные выгрузки, а какая из них исходная - непонятно.
Это продолжает тему большого audit trail. В статье «Audit trail и журналирование операций в SCADA» мы говорили о неизменяемости, хранении и экспорте для аудита. Здесь масштаб уже: ежедневный операторский журнал должен быть пригоден не только для комиссии, но и для нормальной сменной эксплуатации.
Чек-лист: 8 полей записи журнала
Этот чек-лист не заставляет писать роман к каждой операции. Он задает структуру. Для простого входа часть полей будет пустой или автоматической. Для изменения уставки, force или ручного режима поля должны быть заполнены максимально полно.
Как сделать журнал полезным, а не бесконечным
Плохой журнал чаще всего страдает от двух крайностей. В первой пишут почти ничего: только аварии и входы. Во второй пишут все подряд: каждый опрос тега, каждое обновление экрана, системный шум, который никто не читает. Оба варианта плохо помогают эксплуатации.
Рабочий подход спокойнее. Сначала выделяют действия, которые влияют на процесс, безопасность, качество и разбор инцидентов. Затем договариваются, какие поля обязательны. Потом проверяют журнал на реальном сценарии: авария, квитирование, перевод в ручной режим, изменение уставки, возврат в автомат, экспорт. Если по этим строкам можно восстановить историю без звонка всем участникам, журнал уже приносит пользу.
Отдельная тонкость - синхронизация времени. Если SCADA, панель, ПЛК, сервер отчетов и инженерная станция живут в разных временах, даже хороший журнал разваливается. При разборе кажется, что команда пришла после аварии, хотя на самом деле была до нее. Поэтому журнал действий оператора всегда связан с дисциплиной времени на объекте, пусть это и звучит не так эффектно, как новая мнемосхема.
Что не стоит писать в журнал
Журнал действий оператора не должен становиться хранилищем паролей, личных комментариев и длинных технических полотен. Не нужно писать пароль при неуспешном входе. Не нужно хранить персональные данные сверх регламента. Не нужно заставлять оператора вводить причину для каждого просмотра экрана. Если журнал будет мешать работе, его начнут обходить.
Но критичные действия должны быть видны. Изменение уставки без старого значения - плохая запись. Force без снятия - опасная запись. Экспорт без периода - слабая запись. Вход администратора без дальнейших действий - повод проверить, не было ли операции вне журнала. Здесь важна не жесткость ради жесткости, а пригодность для разбора.
Итог
Журнал действий оператора в SCADA - это не архив всех миганий на экране. Это память системы о человеческих действиях: кто вошел, что подтвердил, какую уставку изменил, какой режим включил, где применил force, что выгрузил и с какого рабочего места. Такая память нужна не для наказания, а для нормальной эксплуатации.
Когда событие, авария и действие оператора разделены, разбор становится короче и честнее. Авария показывает, что случилось с объектом. Событие показывает, что заметила система. Действие оператора показывает, что сделал человек. Если эти три слоя собраны в одном читаемом журнале, команда перестает гадать и начинает управлять фактами.
Обсуждение