Синхронизация времени ПЛК, SCADA и журналов: NTP, расхождения и фантомные аварии

Ночная смена сдала объект с формулировкой «два насоса встали, потом связь, потом питание». Утром инженер открывает три журнала: контроллер, панель, сервер архива. Последовательность разъехалась. На ПЛК авария питания раньше обрыва связи, на HMI наоборот, на historian событие «связь потеряна» стоит на минуту раньше пуска насоса. Технолог клянётся, что насос ещё работал. Через час выясняется, что Windows на сервере архива после обновления прыгнул на час, панель жила от RTC с ошибкой 47 секунд, а ноутбук наладчика в момент «разбора» стоял в часовом поясе Екатеринбурга при объекте в другом регионе. Аварии как будто две, линия одна. Разбор смены превращается в спор о часах, а не о клапане.

Разбираем, как расходятся часы контроллера, панели, сервера архива и ПК наладчика, чем NTP отличается от PTP на площадке, как из рассинхрона рождаются «фантомные» аварии и ложный порядок событий, что писать в ТЗ и что проверять на FAT. Не даём курс по теории часов атомного эталона и не разбираем протокол PTP кадр за кадром. Фокус - практика, когда журналы вразнобой и смена уже спорит с КИПиА.

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

Фантомные аварии из журналов чаще всего не «глюки логики», а разные часы у ПЛК, HMI, SCADA и ноутбука. Источник времени на объекте должен быть один: NTP или PTP сервер в OT-сети, доступный контроллерам, панелям и серверам архива. Без него каждый узел живёт своей RTC, Windows тянет интернет-NTP или часовой пояс, Linux RT контроллера остаётся на заводской дате.

В ТЗ фиксируют источник, допустимое расхождение (для обычного технологического контура обычно не хуже 0,5–1 с, для приводов и высокочастотных аварий - жёстче), поведение при потере NTP и запрет ручной установки времени «с панели, чтобы сходилось». На FAT проверяют не «часы тикают», а сценарии: обрыв NTP, перевод DST, перезагрузка контроллера, сверка меток одного события в трёх журналах. Разбор смены без сверки часов - гадание.

Где на объекте живут часы

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

Контроллер держит системное время runtime: Linux RT или встроенный RTC модуля. Это время попадает в журнал ПЛК, в метки retain-событий, иногда в телеметрию OPC UA. Панель оператора - отдельное устройство с собственной RTC, даже если стоит на той же двери шкафа. Сервер архива и SCADA живут временем ОС Windows или Linux. Ноутбук наладчика - четвёртый источник, часто с автосинхронизацией через домашний VPN или с ручным поясом. Шлюз Modbus/OPC, промышленный коммутатор с syslog, ИБП с SNMP - ещё часы, которые всплывают, когда ищут «кто первый моргнул».

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

Отдельно стоит часовой пояс. Объект в Перми, сервер в стойке с поясом UTC+3 «как в офисе», панель в UTC+5 «как на заводе», ПЛК в UTC без пояса. Событие одно, три подписи. DST (перевод часов) на Windows отрабатывает, на контроллере - нет. Два раза в год появляется пачка «повторных» или «пропавших» часов в архиве.

NTP, SNTP и PTP: что реально ставят

На среднем заводе чаще всего NTP или SNTP. Источник - отдельный NTP-сервер в OT, GPS/ГЛОНАСС-часы в щитовой, реже - корпоративный NTP ИТ за межсетевым экраном. Контроллеры и панели ходят клиентами. Windows-сервер SCADA тоже клиент, если его не оставить на time.windows.com через офисный NAT: тогда OT зависит от интернета и от политики ИБ, которая этот NAT рано или поздно закроет.

SNTP проще и грубее: один запрос, нет фильтрации серии измерений. Для журналов аварий с точностью до секунды обычно хватает. NTP с несколькими источниками и алгоритмом отбора устойчивее к «уехавшему» серверу. PTP (IEEE 1588) нужен там, где важны миллисекунды: синхронные приводы, регистрация аварий на шине, совмещение осциллограмм. Ставить PTP «на всякий случай» на насосную станцию с циклом 50 мс - лишние коммутаторы и головная боль, если нет задачи.

Иерархия источников должна быть явной. Один stratum на площадке, остальные - клиенты. Два равноправных NTP без понимания, кто master, дают ситуацию, когда половина шкафов слушает GPS в щитовой, половина - ноутбук наладчика, который когда-то включил «раздавать время». После отъезда ноутбука контроллеры либо замирают на последней оценке дрейфа, либо начинают жить RTC.

Поведение при потере NTP важнее самой галочки «NTP включён». Варианты: держать последний ход RTC (дрейф кварца - секунды-минуты в сутки на дешёвых часах), заморозить метки, перейти на запасной источник. Для технологического журнала обычно оставляют ход RTC и поднимают диагностический бит «время не синхронизировано». Этот бит должен быть виден на HMI и в архиве. Иначе через неделю никто не докажет, что метки уже «резиновые».

Как из секунд рождается фантомная авария

Классика. Контроллер генерирует аварию «давление ниже уставки» в 03:12:08 по своим часам. Панель показывает то же по своим, но она на 90 секунд впереди. Оператор квитирует в 03:13 по панели. Сервер архива, отстающий на две минуты, пишет квитирование раньше появления аварии. Утром отчёт «сначала сбросили, потом случилось». Разбор идёт по ложному причинно-следственному следу: ищут, кто сбросил защиту, хотя сброса не было - была рассинхронизация.

Второй сюжет - скачок времени. Windows после обновления или после включения «автоматически задавать время» прыгает на час. Historian переписывает метки или принимает новые события «из прошлого». Тренд рисует полку, потом обрыв, потом повтор значений. Смена видит «аварию связи». Связи не было: часы скакнули, буфер меток сломал монотонность.

Третий сюжет - двойная запись одного события. Шлюз ставит свою метку, SCADA - свою. При опросе раз в секунду и расхождении 800 мс одно и то же дискретное «авария насоса» в журнале выглядит как два импульса. Оператор получает два пуша, два красных баннера, ощущение «система сыпется». Логика ПЛК при этом штатная.

Четвёртый - «будущее» в журнале ПЛК. Наладчик вручную выставил на контроллере дату «чтобы совпало с ноутбуком», ноутбук был в поясе командировки. После отъезда контроллер пишет события «на сутки вперёд». Архив либо отбрасывает их как некорректные, либо кладёт в завтра. Утром смена не находит ночную аварию в отчёте за календарные сутки.

Такие фантомы дорого стоят не железом, а временем разбора и ложными претензиями к подрядчику. Пока часы не сведены, спорить о порядке блокировок бессмысленно.

Windows, Linux RT и RTC: почему они разъезжаются сами

Windows любит интернет-NTP, доменный контроллер и часовой пояс пользователя. Сервер SCADA в домене ИТ получает время от DC, DC - от внешнего NTP, OT-контроллеры - от GPS в щитовой. Два дерева часов. Рассинхрон 1–3 с - нормальная картина, пока ИТ не переведёт DC, а GPS не «моргнёт» при плохой антенне.

Linux RT на контроллере обычно честнее: нет сюрпризов с DST, если не настроили tzdata. Зато RTC без батарейки после длительного обесточивания шкафа стартует с 1970 или с даты прошивки. Первый цикл после питания пишет события в «эпоху». Если архив принимает всё подряд, в отчёте за 2026 год всплывает пачка записей 1970-го. Фильтр «отбрасывать метки старше N часов от сервера» спасает отчёт и маскирует факт, что контроллер не синхронизировался после freeze.

Батарейка RTC - расходник, о котором вспоминают, когда шкаф постоял без питания на складе. В паспорте объекта стоит дата замены. На приёмке проверяют, что после снятия питания на час контроллер не уехал на минуты. Иначе зимний простой линии даст весенний сюрприз в журналах.

Ноутбук наладчика - главный вредитель монотонности. Online-отладка, force, запись трассировки с метками ПК вместо меток ПЛК. Файл «trace_final.csv» с временем Windows смешивают с журналом контроллера. Правило простое: для официального разбора годятся только метки узлов, синхронизированных с площадочным источником. След ноутбука - черновик.

Журналы, тренды и OPC: где метка рождается

Метка времени может появиться в четырёх местах, и это не одно и то же.

Источник в ПЛК: событие родилось в цикле, метка - часы runtime. Это золотой стандарт для причинно-следственного разбора логики. Источник на шлюзе: шлюз получил регистр и поставил своё время. Опрос 500 мс плюс очередь - погрешность уже сравнима с коротким импульсом аварии. Источник на SCADA: тег изменился при опросе, метка - часы сервера. Для медленной температуры приемлемо, для дискретной блокировки - лукавство. Источник OPC UA: сервер может отдать SourceTimestamp с контроллера и ServerTimestamp с самого себя. Если клиент архивирует не ту метку, разбор снова едет.

При запуске OPC UA это один из пунктов, который пропускают: «связь есть, теги живые». На FAT нужно явно сказать, какая метка идёт в historian. Иначе через год два подрядчика будут сравнивать разные шкалы.

Локальный журнал панели полезен оператору и опасен как «истина» для комиссии. Панель может буферизовать аварии при обрыве и выгрузить их пачкой с собственными часами. Выглядит как шторм. Отладка на объекте с журналом оператора как раз учит не путать след HMI и след ПЛК. Для RCA оставляют журнал контроллера плюс архив с согласованной меткой.

Граница уставок между панелью и SCADA добавляет ещё один слой: кто и когда поменял уставку, чьи часы в audit trail. Это соседняя тема границы панели и SCADA, но без единого времени audit trail превращается в набор несопоставимых строк.

Что писать в ТЗ и паспорте объекта

Формулировка «синхронизация времени NTP» без цифр - декорация. В техническом задании нужны проверяемые пункты.

Единый источник времени площадки: тип (NTP/PTP), размещение, резервирование, кто владеет (АСУ, ИТ, энергетика). Клиенты: перечень контроллеров, панелей, серверов SCADA/historian, шлюзов, устройств syslog. Допустимое расхождение в нормальном режиме и максимальный дрейф за 24 часа без NTP. Поведение при потере источника: диагностический сигнал, запрет скрытого перехода на интернет-NTP. Запрет ручной установки времени оператором; разрешение - роли наладчика с записью в audit. Часовой пояс объекта и правило DST: либо везде локальное с одной политикой, либо везде UTC в архиве и локальное только на экране. Требование монотонности меток в historian: что делать со скачком назад и со скачком вперёд.

В пакете документов при вводе должен появиться лист сверки часов: узлы, источник, расхождение на дату SAT, скрин или протокол NTP. Без этого через год никто не докажет, что в момент аварии часы ещё жили.

Для объектов с претензией на быстрый разбор аварий имеет смысл требовать SourceTimestamp с контроллера в архиве дискретных событий. Опросная метка сервера для RCA блокировок - заведомый компромисс.

Что проверять на FAT и SAT

На FAT и SAT время проверяют сценариями, не взглядом на часы в углу экрана.

Сверка одного события. Искусственно вызывают дискретную аварию (концевик, кнопка, force на стенде). Фиксируют метку в журнале ПЛК, на панели, в SCADA, в historian. Расхождение записывают в протокол. Если больше согласованного допуска - не «потом наладчик подкрутит», а дефект.

Обрыв NTP на 10 минут, час, сутки. Контроллеры продолжают ход. Диагностический бит виден. После восстановления NTP нет скачка, ломающего архив, либо скачок документирован и historian его пережил без дублей.

Перезагрузка контроллера и сервера. После старта синхронизация происходит до появления «боевых» записей в архив, либо ранние записи помечены как ненадёжные по времени.

Перевод часов / DST, если пояс локальный. Повторов и дыр в тренде нет, либо они описаны в инструкции эксплуатации.

Ручная попытка сменить время с роли оператора - отказ. С роли инженера - запись в журнал с пользователем.

Ноутбук наладчика в другом поясе не должен становиться источником NTP для шкафа. На FAT это проверяют просто: включают раздачу времени на ПК и смотрят, не переключились ли клиенты. Если переключились - архитектура источника дырявая.

SAT на живой линии добавляет сверку с внешним эталоном (телефон с сетью, GPS-часы мастера), но эталон - не интернет на том же ноутбуке, который уже состоит в конфликте интересов.

Таблица: симптом в журналах, причина времени, проверка

Типовые ошибки

Оставить сервер SCADA на интернет-NTP, контроллеры - на GPS щитовой. Два дерева часов. В тихой жизни расхождение секунды, в разборе - противоречивые акты.

Разрешить оператору «подкрутить часы на панели, чтобы сходилось». Через месяц панель снова уедет, плюс пропадёт след, кто менял время в ночь аварии.

Не выводить диагностику потери NTP на HMI. Часы «как будто идут», метки уже непригодны для RCA. Смена не знает, что журнал уже не доказательство.

Смешать SourceTimestamp и ServerTimestamp в одном отчёте. Комиссия сравнивает яблоки с секундами опроса.

Забыть батарейку RTC и поведение после freeze. Весенний пуск после зимы даёт пачку фантомных дат в архиве.

Принять FAT по скриншоту часов в углу мнемосхемы. Часы на экране могут быть временем клиента визуализации, не контроллера.

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

Нужен ли PTP вместо NTP на обычной насосной и вентустановке?
Как правило нет. PTP оправдан, где миллисекунды входят в задачу измерения или синхронного движения. Для журналов аварий и трендов с периодом секунды хватает NTP с допуском до 0,5–1 с.

Что делать, если ИТ запрещает GPS-сервер в OT и навязывает доменный NTP?
Допустимо, если OT-клиенты ходят к этому источнику предсказуемо, без скачков при обновлении DC, и если диагностируется обрыв. Зафиксировать владельца и SLA на время. Два независимых «главных» источника - хуже, чем один согласованный.

Можно ли жить в UTC в архиве и в локальном времени на HMI?
Да, и часто это спокойнее, чем DST на контроллере. Тогда в ТЗ явно: архив UTC, экраны - пояс объекта, в отчётах указывать пояс. Путаница начинается, когда часть узлов пишет локальное, часть UTC, без подписи.

Как разбирать аварию, если часы уже разъехались?
Сначала измерить текущий offset каждого узла и не двигать часы до снятия копий журналов. Дальше строить шкалу «плюс-минус известный сдвиг», а не править метки в файлах. Правка меток задним числом уничтожает доказательную базу.

Кто отвечает за время: АСУ или ИТ?
Владелец источника должен быть один и назван в паспорте. Эксплуатация АСУ отвечает за клиентов в шкафах, ИТ - за серверы, если источник в их контуре. Серая зона «оба» даёт ноль ответственных в 03:00.

На практике

На контроллере с Linux RT клиент NTP обычно есть в системе, но «есть» не равно «ходит к вашему серверу». После монтажа проверяют, что ПЛК и панель смотрят на тот же источник, что и сервер архива, а не на случайный пул из поставки образа. Для линейки СТАБУР это тот же инженерный жест, что и для любого Linux RT контроллера: прописать сервер, увидеть offset, вывести бит потери синхронизации в проект, а не надеяться, что часы на экране совпали с телефоном наладчика.

Ссылки по теме

• FAT и SAT: приёмка АСУ ТП без сюрпризов на пуске;
• Отладка HMI: объект, симуляция, force, журнал оператора;
• HMI оператора: иерархия экранов, аварии и тренды без перегруза;
• Панель оператора и SCADA: граница уставок и аварий;
• Пакет документов при вводе АСУ ТП в эксплуатацию;
• OPC UA для инженера АСУ ТП: запуск.