Пинг до контроллера есть. На панели горит зелёный RUN. По SSH (если его оставили) systemctl status показывает runtime active. Насос не слушается уставки уже две минуты. Оператор звонит: «связь вроде есть, управления нет». Наладчик лезет в task monitoring и видит: период задачи 20 мс, фактический цикл 200, overrun счётчик растёт, выходы застыли в последнем значении. Аппаратный watchdog ещё не укусил: процесс ОС жив, светодиод доволен, технология мертва.
Разбираем три разных «живости» ПЛК на Linux RT: аппаратный сторожевой таймер платы, процесс runtime под systemd (или аналог), цикл задачи IEC 61131-3. Диагностика «пинг есть, управление нет» - это расхождение этих трёх, а не одна кнопка Reset. Соседняя тема - ПЛК в STOP после watchdog и не уходит в RUN: там runtime уже зафиксировал fault и не стартует. Здесь чаще хуже: STOP нет, все индикаторы «как надо», цикла управления нет. Не учебник по ядру Linux и не сравнение Windows Runtime как среды разработки: слои ОС при переносе проекта - в материале про Linux RT и Windows.
У контроллера на Linux RT три независимых жизни. Железо (питание, CPU, аппаратный WDT) может быть живо, пока процесс runtime уже завис. Процесс может быть active в systemd, пока задача IEC сорвала период и не пишет выходы. Задача может формально завершать скан, пока логика стоит в блокирующем вызове и управление «как будто есть».
Диагностика идёт сверху вниз: пинг и порт - не управление; RUN LED и systemctl active - не цикл; цикл в норме - ещё не значит, что прикладная логика двигает исполнительные механизмы. Таблица индикаций ниже. Лечить «перезагрузил, помогло» без слоя - лотерея: аппаратный WDT, рестарт юнита и STOP/RUN задачи - три разных действия с тремя разными последствиями для выходов.
Инженер говорит «контроллер завис». На Linux RT это четыре разных события, и «завис» маскирует все.
Жизнь 1: плата. Ядро живо или мёртво, питание 24 В в допуске, аппаратный watchdog (WDT) либо тикает от драйвера, либо уже режет reset. Если плата мертва, пинга нет, светодиоды погасли или горят fault по паспорту, SSH молчит.
Жизнь 2: процесс runtime. Пользовательский (или привилегированный) процесс среды исполнения: CODESYS runtime или MasterSCADA 4D на том же железе - равнозначные варианты заказа, не «ПЛК vs SCADA». Systemd считает его active, если процесс не вышел и отвечает на watchdog юнита (если юнит с WatchdogSec=). Процесс может крутиться в эпилоге, в deadlock, в ожидании сети - и всё равно быть active.
Жизнь 3: задача IEC. Периодический скан программы. Watchdog задачи в среде (interval + watchdog time) следит, что скан завершился. Если скан не завершился - классический путь в STOP, это статья про STOP после watchdog. Если скан завершается, но делает это за 200 мс при периоде 20 мс, часть сред ставит overrun и продолжает, не уходя в STOP. Выходы обновляются редко, регулятор разваливается, связь внутри цикла плывёт. Пинг при этом отличный.
Жизнь 4, про которую забывают: прикладная логика. Скан идёт вовремя, а внутри IF NOT bEnable THEN RETURN навсегда, или команда с HMI не доходит из-за качества тега, или задача I/O в стопе. Индикаторы ещё красивее.
Путать жизнь 2 и жизнь 3 - главный источник фразы «процесс жив, цикл мёртв». Systemd не знает про IEC-задачу. Аппаратный WDT не знает про overrun 20 мс. Среда может не знать, что ядро уже в soft lockup.
На ARM-плате промышленного контроллера аппаратный сторожевой таймер сидит в SoC или в отдельной микросхеме. Его обязан «гладить» драйвер ядра или сервис, пока система считается здоровой. Если ядро зависло, драйвер не гладит - плата уходит в reset через заданные секунды (часто 8–32 с, смотрите паспорт, не фольклор).
Что аппаратный WDT не ловит:
живой idle ядра при мёртвой задаче IEC;
процесс runtime в deadlock, если именно этот процесс не привязан к аппаратному WDT (гладит кто-то другой: systemd, отдельный wdt-демон);
медленный overrun цикла: ядро счастливо, процесс счастлив, технология нет.
Что ловит: полный hang ядра, вечный soft lockup без обслуживания WDT, некоторые зависания init, если цепочка «кто гладит» оборвалась.
На объекте проверка аппаратного слоя - не «написать бесконечный цикл в ST». Бесконечный цикл в задаче должен поймать watchdog задачи, иначе вы тестируете не то. Аппаратный проверяют по паспорту изготовителя (сервисный режим, регламент FAT) или косвенно: после зависания ядра должен быть reboot, в журнале - reset reason watchdog, не power-on. Если ядро зависло, а reset не пришёл за время WDT - цепочка «кто гладит» слишком оптимистична: гладит демон, который не зависит от здоровья runtime.
Связка, которую стоит требовать у поставщика образа: аппаратный WDT гладит только если живы ядро и процесс runtime. Иначе Linux может вечно гладить железо, пока IEC мёртв. Это настройка образа, не «галочка в ST». Её проверяют на FAT вместе с ОСРВ и временем цикла, не на живом насосе.
Юнит runtime в типичном образе выглядит как служба с Restart=, иногда WatchdogSec=, иногда Type=notify. Systemd watchdog - это ещё одни часы: процесс должен периодически слать sd_notify(WATCHDOG=1). Если не шлёт - systemd убивает и, по политике, перезапускает процесс.
Полезное:
процесс упал (segfault) - юнит failed или ушёл в рестарт, это видно;
процесс перестал notify - рестарт по WatchdogSec;
после рестарта прикладной проект может подняться в STOP или в RUN - зависит от среды и retain. Это уже не «тихий» сбой.
Бесполезное как доказательство управления:
active (running) при сорванном цикле IEC: процесс шлёт notify из низкоприоритетного потока, а задача 20 мс стоит;
active при блокировке в драйвере OPC: notify идёт, сканы нет;
рестарт юнита каждые N минут «сам лечится»: линия дёргается, уставки в retain могут выжить, исполнительные механизмы - нет.
На диагностике смотрят не одну строку status, а: uptime процесса (если 12 секунд при работе смены 8 часов - уже рестартовал); счётчик рестартов; журнал ядра reset reason; task overrun в среде. SSH на объекте - спорный канал; если его нет, те же данные должны быть в веб-диагностике/IDE online/syslog, иначе «systemd active» останется легендой интегратора.
Политика рестарта: автоматический рестарт runtime на технологическом контроллере - решение проекта, не дефолт Linux «чтобы горел». Каждый рестарт - провал выходов в безопасное или в last value на время подъёма. Если это насос без ПАЗ, last value может быть хуже STOP. Фиксируют в матрице: при смерти процесса выходы в 0 / hold / переход на резерв. Горячий резерв ловит смерть процесса иначе, чем одиночный CPU: см. резервирование и watchdog на FAT. Здесь важнее не путать рестарт systemd с failover.
Watchdog задачи в среде настроен на «скан не завершился за T». Сценарий STOP разобран в статье про STOP после watchdog. Второй, более противный сценарий 2026 года на загруженных панельных контроллерах: скан завершается, но с постоянным overrun.
Причины, которые не роняют процесс:
визуализация и OPC UA на том же CPU съели кванты, задача управления получила CPU позже периода;
синхронный обмен в скане (ждать ответ Modbus в том же цикле);
тяжёлый FOR, запись на eMMC, разбор строки в горячей задаче;
thermal throttle: частота CPU упала, цикл вырос, все «живы». Перегрев шкафа даёт ту же картину с другими уликами: см. derating и вентиляторы.
Среда может: копить overrun, слать warning, не переводить в STOP, потому что watchdog задачи настроен шире периода («interval 20 мс, watchdog 200 мс»). Формально скан укладывается в 200, технология на 20 мс контуре - нет. Пинг, LED, systemd - зелёные.
Диагностика цикла: max/min/avg cycle, overrun counter, jitter, загрузка CPU по задачам, не общий %idle Linux. %idle высокий не доказывает, что задача 20 мс уложилась: idle считает ядро, задачу считает runtime. На FAT предел цикла и джиттера должны быть цифрами ТЗ, не «в целом RT».
Третий подвид: задача жива, I/O-шина нет. EtherCAT/модули в ошибке, выходы в failsafe, программа считает «как будто». Индикация runtime RUN, цикл в норме, поле мёртво. Проверка - диагностика мастера шины и модулей, не ping CPU.
Порядок, который экономит час на объекте.
Что именно «нет управления»: не двигается выход, не идёт обмен с частотником, не пишется уставка с HMI, не обновляется вход. Это разные слои.
Индикаторы платы: RUN/STOP/ERR по паспорту, не «зелёненький вообще».
Связь: ICMP ping доказывает только IP-стек. Откройте штатный протокол (Modbus/OPC): качество тегов, таймауты, счётчик транзакций. Пинг жив, порт 502 мёртв - это не цикл IEC, это сеть/сервис.
Online среды: состояние PLC (RUN/STOP), задачи, cycle time, last error. Если STOP - уходите в сценарий безопасного пуска после watchdog задачи, не в systemd.
Если RUN и cycle раздут - снимайте нагрузку: визуализация, архив, лишние клиенты OPC. Не reboot первым движением.
Если RUN, cycle в норме, выходы не те - смотрите прикладную блокировку, force, качество входов, состояние PackML/автомата, ручной режим.
Если online среды не открывается, а пинг есть - процесс мог зависнуть без STOP: тогда смотрите доступную диагностику ОС (веб, syslog, консоль изготовителя). Рестарт юнита - осознанно, с пониманием выходов. Рестарт платы (аппаратный reset) - последнее, с протоколом: это cold start для retain/persistent.
Питание 24 В и температура: brownout и throttle дают «всё живое и всё плохое» без единого exception.
Не используйте бесконечный ping как мониторинг здоровья ПЛК. ICMP не гладит ни задачу, ни WDT. Для мониторинга нужен признак цикла: счётчик сканов, heartbeat тег, диагностический бит «задача уложилась», SNMP/syslog с overrun, не echo request.
| Индикация | Что это значит | Проверка |
|---|---|---|
| Нет ping, LED погасли / fault питания | Скорее жизнь 1: питание, reset, мёртвое ядро | 24 В на клеммах, reset reason после подъёма, не лечить ST |
| Нет ping, LED RUN | Сеть, VLAN, firewall, чужой IP; плата может быть жива | Локальный сервисный порт, ARP, не reboot «на всякий» |
| Ping есть, порт среды/OPC не открывается | Стек IP жив, сервис runtime нет или фильтр | Статус юнита, слушающие порты штатной диагностикой изготовителя, журнал рестартов |
| systemd `active`, uptime процесса секунды | Жизнь 2: юнит рестартует по кругу | Счётчик рестартов, crash log, не считать «работает» |
| systemd `active`, uptime часы, RUN LED | Процесс жив; цикл неизвестен | Task monitoring: cycle, overrun, watchdog задачи |
| RUN LED, цикл в допуске, выходы застыли | Жизнь 3 ок, поле или приклад: шина I/O, force, блокировка | Диагностика модулей, карта force, автомат/Held/Abort |
| RUN, overrun растёт, STOP нет | Сорванный период при живом процессе | CPU задач, visu/OPC нагрузка, температура, синхронные вызовы в скане |
| STOP, watchdog timeout задачи | Скан не завершился: классический fault среды | Журнал exception, не systemd; безопасный пуск по статье про STOP |
| Аппаратный reset по WDT в логе, потом cold start | Ядро/цепочка глажки умерли | Почему не гладили: hang ядра, убитый wdt-демон, питание |
| Все зелёные, HMI не пишет уставку | Не watchdog, а роль/качество/другой клиент | Карта тегов, Bad Quality, сессия HMI |
| Периодический саморестарт без аварии на HMI | WatchdogSec systemd или WDT платы в петле | Сопоставить период рестарта с настройкой юнита/WDT, искать hang |
Таблица для ночной смены: три колонки читаются быстрее, чем dmesg. Её же можно вложить в регламент дежурного: какое сочетание - звонок электрику, какое - наладчику, какое - «не жми Run».
Когда среда перевела PLC в STOP по watchdog задачи, индикация честная: не RUN. Дальше - поиск причины скана, безопасный пуск, не рестарт systemd «чтобы моргнуло». Рестарт процесса в STOP может поднять ту же exception через секунду.
Когда STOP нет, а управления нет - рестарт systemd маскирует overrun и deadlock на минуту. Симптом уходит, причина нет. Через час снова. В журнале объекта должна быть жизнь 2 (рестарт юнита) отдельно от жизни 3 (overrun) и жизни 1 (WDT reset). Иначе утром все «забыли», какой слой дёргали: тот же эффект, что в ночном разборе без пакета данных.
Настройка «широкий watchdog задачи, чтобы не уходить в STOP на пиках» покупает доступность индикатора ценой мёртвого контура. Иногда это осознанно (не рвать линию на кратком пике визуализации). Тогда обязателен отдельный сигнал «overrun > N» на HMI и в историк. Иначе вы продали молчаливую смерть цикла за зелёный RUN.
Считать ping критерием здоровья ПЛК. ICMP не цикл и не выходы.
Считать systemctl active циклом. Notify юнита дешевле скана 20 мс.
Гладить аппаратный WDT из демона, который не зависит от runtime. Ядро вечно живо, технология нет.
Расширить watchdog задачи «чтобы не пищал». STOP пропал, управление тоже.
Первым действием reboot платы. Стирается overrun, exception, uptime процесса. Сначала снять индикации.
Бесконечный цикл в ST как тест аппаратного WDT. Это тест watchdog задачи, если он настроен; иначе - тест «как уронить линию».
Игнорировать температуру и 24 В. Живые процессы на задушенном CPU выглядят как загадка ПО.
Не логировать рестарты юнита. Смена видит «моргнуло», утром причин нет.
Путать last value выходов при рестарте процесса с безопасным STOP. Для привода это разные миры.
Почему пинг есть, а online среды не коннектится?
IP-стек ядра жив, процесс runtime нет или не слушает порт. Это жизнь 2, не жизнь 3. Смотрите рестарты юнита и порты штатной диагностики, не cycle time.
Нужно ли на каждом ПЛК держать SSH?
Не обязательно и часто вредно. Нужен канал диагностики трёх жизней: LED, online среды, syslog/веб изготовителя. SSH - один из каналов, не условие RT.
Кто должен гладить аппаратный WDT?
Цепочка, завязанная на здоровье runtime, не на «ядро ещё планирует». Иначе аппаратный слой врёт так же, как ping.
Что делать, если overrun есть, STOP нет?
Считать это аварией контура, не warning для программиста. Снижать нагрузку, выносить visu/архив, убирать блокирующие вызовы, чинить тепло. Расширять watchdog - в последнюю очередь и с сигналом на HMI.
Рестарт systemd безопаснее reset платы?
Обычно да для retain и быстрее по времени, но выходы всё равно переживают провал. Матрица выходов обязана знать оба события. Reset платы - если не поднимается ядро или WDT уже режет сам.
Это то же самое, что ПЛК не уходит в RUN после STOP?
Нет. Там fault уже зафиксирован, задача не играет. Здесь индикаторы могут врать, что всё RUN. Путать лечение опасно: Run на STOP без причины и reboot при живом STOP - разные ошибки.
Как проверить на FAT расхождение трёх жизней?
Стенд: (а) нагрузка visu/OPC до overrun без STOP - должен быть сигнал, не тишина; (б) убийство процесса runtime - WDT или systemd поднимают по регламенту, выходы в безопасное, запись в журнал; (в) зависание тестовой задачи - STOP среды, не «зелёный ping». Три протокола, не один «watchdog ок».