Логи SCADA-систем: что писать, чтобы потом найти ошибку

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

Я много лет работал с АСУ ТП и SCADA-системами, и могу сказать честно: подход к логированию здесь совсем другой. То, что прощает веб-приложение, в промышленности убивает.

Чем SCADA-логи отличаются от всего остального

Давайте сразу обозначим разницу.

В обычной разработке мы логируем, чтобы понять, почему упал сервер или где ошибка в коде. Нам важны stack trace"ы, debug-сообщения, детали запросов.

В SCADA логи — это: - Доказательство того, что технологический процесс протекал штатно - Улика при расследовании аварий - Основа для прогнозирования отказов - Документ, который могут затребовать регулирующие органы

Здесь нельзя просто «почистить логи» или сказать «оно само прошло». Здесь логи хранят годами и используют как улики в судах .

Что писать: базовый набор

Опираясь на опыт и требования промышленных стандартов , вот что должно быть в логах обязательно.

1. Технологические параметры

Это «жизненные показатели» процесса: давления, температуры, расходы, уровни, обороты.

Как писать правильно:

Не всё подряд. Эксперты советуют: логируйте только то, что действительно важно . Если вы будете писать каждую миллисекунду с датчика давления, где шум 0.5%, через месяц уто́нете в данных, а сервер захлебнётся.
Используйте мёртвые зоны (deadbands). Записывайте значение, только если оно изменилось больше чем на заданный порог. Это сокращает объём логов в десятки раз без потери информативности .
Настраивайте интервалы. Для одних параметров достаточно опроса раз в минуту, для других нужна миллисекундная фиксация .

В современных SCADA есть два типа логирования : - Непрерывное — пишем всегда, для постоянных процессов - Триггерное — пишем только при наступлении события (ошибка, авария, смена режима)

2. Дискретные сигналы и состояния

Включился насос, открылась задвижка, сработала блокировка — всё это должно фиксироваться.

Важно: фиксируйте не только факт, но и контекст. Кто дал команду? Из какого режима? С какими параметрами?

3. Аварии и события

Это сердце SCADA-логирования. Здесь нужен максимальный уровень детализации :

Время появления сигнала (до миллисекунд, если возможно)
Время квитирования (подтверждения оператором)
Время снятия (возврата в норму)
Приоритет события (информация, предупреждение, авария)
Текущие значения связанных параметров на момент события

Пример из жизни: Упало давление в маслосистеме турбины. В логе должно быть не просто "Pressure low", а: 2026-03-03 14:23:45.123 ALARM Pressure low (P-101) value=0.3 bar (threshold=1.5 bar) 2026-03-03 14:23:45.124 INFO Pump P-101 status=RUNNING 2026-03-03 14:23:45.125 INFO Valve V-201 position=100% 2026-03-03 14:23:46.890 EVENT Operator "Ivanov" ACKNOWLEDGED alarm 2026-03-03 14:23:47.120 EVENT Auto-start of backup pump P-102 initiated

4. Действия оператора

В промышленности это критически важно. Кто, когда и что нажимал, должен быть задокументировано .

Вход/выход из системы
Изменение уставок и параметров
Подтверждение аварий
Ручное управление исполнительными механизмами

Совет: логируйте не просто "operator changed parameter", а "operator Petrov changed pressure setpoint from 2.5 to 3.0 bar at 14:23:45". Это спасёт при разборе, кто виноват.

5. Системные события SCADA

Сюда входит: - Запуск/остановка серверов - Сбои связи с контроллерами - Переполнение архивов - Ошибки лицензий

Опытные специалисты знают: часто проблема не в «железе», а в том, что SCADA потеряла связь с контроллером и час работала «вслепую» .

Как писать: технические хитрости

Проблема дублирования

В SCADA есть неприятная особенность: при сбоях связи система начинает генерировать лавину однотипных сообщений. В одном форуме Siemens обсуждали случай, когда из-за потери связи с контроллером лог-файлы раздулись до 2 ГБ за пару часов .

Что делать: - Настраивать подавление повторяющихся аварий (похоже на фильтрацию в syslog) - Использовать механизмы подтверждения связи - Для критичных случаев — писать скрипты чистки логов от "шума"

Сжатие и агрегация

Промышленные системы работают годами. Логи за 5 лет могут занимать терабайты. Современные SCADA умеют сжимать данные "на лету", сохраняя тренды, но отбрасывая шум .

Механизм такой: - Сырые данные хранятся неделю-месяц - Затем агрегируются в минутные/часовые интервалы - Долгосрочно хранятся только статистики: min, max, average за период

Резервирование

Потерять логи в промышленности — это катастрофа. Поэтому обязательно : - Резервирование серверов архивации (активный-пассивный или активный-активный) - Географически распределённое хранение (не храните всё в одном цехе — сгорит) - Регулярное тестирование восстановления из бэкапов

Где искать логи

Каждый вендор прячет логи по-своему. Вот шпаргалка по популярным системам.

Schneider Electric / Geo SCADA

Для диагностики OPC UA сервера используется aaLogViewer.exe (лежит в C:\Program Files (x86)\Common Files\ArchestrA). Там можно включать флаги логирования для конкретных компонентов и выгружать логи для поддержки .

Коммуникационные логи делятся на TX (передача) и RX (приём), с подробными статусами: - Rx ACCEPTED — пакет принят - Rx REJECTED — данные прочитаны, но отброшены (неверный формат) - Rx FAILED — ошибка контрольной суммы - Rx PURGED — обрыв связи

Siemens WinCC Unified

В TIA Portal V20 появились встроенные функции управления логированием: - StartTagLog / StopTagLog — для тегов - StartAlarmLog / StopAlarmLog — для аварий - StartAuditLog / StopAuditLog — для действий оператора

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

Где лежат логи: C:\Users\[username]\AppData\Roaming\MPSSoft\MasterSCADA4D\[version]\ProjectsServiceData\[project]\Debug\[node]\PLC\logs

MasterSCADA

Для диагностики обмена по SNMP включается ключ /t в параметрах запуска, после чего логи пишутся в отдельную папку. В логах ищите строки "SNMP driver" .

Bentley SCADAConnect

Если не грузятся данные, включайте Advanced Logging. Логи будут в C:\Users\[user]\AppData\Local\Bentley\[product]\SCADAConnect.log .

Как настроить, чтобы потом найти

1. Используйте цвет и приоритеты

Современные SCADA (например, ESAWARE CREW) позволяют раскрашивать события: - Информационные — серым или зелёным - Предупреждения — жёлтым - Ошибки — оранжевым - Аварии — красным

Это критически важно для оператора, который в стрессе должен мгновенно оценить ситуацию .

2. Добавляйте контекст

Одно дело — "ошибка датчика". Другое — "ошибка датчика давления P-101, текущее значение 0.0, ожидалось 2-4 bar, предыдущее исправное значение 2.3 bar 2 секунды назад".

Контекст — это то, что превращает логи из набора цифр в расследование.

3. Синхронизируйте время

Золотое правило промышленной автоматизации: все устройства должны иметь синхронизированное время.

Если контроллер считает, что сейчас 14:23, а SCADA — что 14:25, вы никогда не восстановите хронологию событий. Используйте NTP-серверы и проверяйте синхронизацию.

4. Настройте допуски по времени

При запросе исторических данных из SCADA в смежные системы (например, в MES или ERP) используйте временны́е допуски. Если SCADA опрашивает контроллер раз в минуту, а вам нужны данные на 12:00:00, разумно брать значения с 11:57:30 до 12:02:30 .

Типичные грабли (на своих ошибках)

Грабли 1: Логировать всё подряд

Был у меня случай: на объекте включили логирование всех тегов с частотой 100 мс. Через неделю архивы заняли 500 ГБ, SCADA начала тормозить, а операторы не могли открыть тренды за последний час.

Решение: Включили голову, оставили только критичные параметры с частотой 1 сек, для остальных — изменения больше 1% .

Грабли 2: Игнорировать качество данных

В SCADA Siemens есть понятие "качество тега" (quality). Если связь с контроллером пропадает, теги получают статус "bad" (quality code 0x14). Но многие забывают, что такие "плохие" данные тоже пишутся в архив и засоряют логи .

Более того, при восстановлении связи система может сгенерировать тысячи аварий о восстановлении качества, которые не несут полезной информации.

Что делать: Настраивайте фильтрацию событий по качеству. Например, в WinCC Unified можно через скрипты чистить логи от записей с определённым кодом ошибки .

Грабли 3: Не тестировать восстановление

"У нас есть бэкапы!" — самая опасная фраза в IT и АСУ ТП. Проверьте, сможете ли вы реально восстановить логи годичной давности, если сервер сгорит. И сколько времени это займёт.

Грабли 4: Забывать про регуляторов

Если объект подпадает под регулирование (например, водоканал по стандарту DWA-M 260), требования к логам жёстко прописаны : - Фиксировать все вмешательства оператора - Хранить данные определённое время - Обеспечить невозможность подделки

Лучше закладывать compliance на этапе проектирования, чем переделывать работающую систему.

Промышленный чек-лист

Если вы проектируете или модернизируете SCADA-систему, вот что должно быть в техническом задании на логирование:

[ ] Определён перечень технологических параметров с указанием периодичности опроса и мёртвых зон
[ ] Настроены уровни аварий и цветовая индикация
[ ] Включено логирование действий оператора с привязкой к учётным записям
[ ] Настроена синхронизация времени (NTP)
[ ] Определены сроки хранения и политика агрегации
[ ] Настроено резервирование серверов архивации
[ ] Проведено тестирование восстановления из бэкапов
[ ] Для объектов с регулированием — проверено соответствие стандартам
[ ] Настроена фильтрация "мусорных" событий (повторы, плохое качество)

Вместо заключения

Знаете, чему меня научили годы работы с промышленными системами? Логи в SCADA — это не просто файлы для отладки. Это единственный источник правды о том, что реально происходило на объекте.

Когда расследуешь серьёзную аварию, каждый параметр, каждая миллисекунда, каждое действие оператора становятся уликами. И если логи настроены плохо — вы никогда не узнаете истинную причину. Оборудование спишут на «человеческий фактор» или «внезапный отказ», а настоящая проблема останется и убьёт следующий агрегат.

Поэтому я всегда говорю заказчикам: закладывайте на логирование не меньше 10-15% бюджета автоматизации. Дешёвые логи выходят дороже.

И помните главное: SCADA пишет не для галочки. Она пишет для того дня, когда случится ЧП и вам придётся отвечать на вопрос «Почему это произошло?». Сделайте так, чтобы в этот день у вас были ответы.