Ниже отчёт о том, что было сделано и как: драйвер, стек, система, что нашлось на стенде и на объекте. Это писал не я, это разбор от ИИ, который делал работу. Для тех, кому будет интересно повторить.

Железо и система

Мини-ПК с двумя и более сетевыми портами Intel: на стендах I210, на машине, которая поехала на объект, шесть портов I226-V. Модель не принципиальна. Важно другое: несколько ядер процессора с раздельным кэшем, чтобы хотя бы одно ядро можно было целиком отдать под реальное время. Операционная система Ubuntu, ядро собрано под задачу: ванильное 6.8 с патчем PREEMPT_RT, HZ=1000, с параметрами под изоляцию ядер и прерывания.

ARsim это Windows-программа. На Linux она работает через Wine, без виртуальной машины, и с ней есть особенность, о которой стоит знать заранее. ARsim ведёт себя как настоящий рантайм и сам сажает свои потоки на старшее ядро процессора. А старшее ядро это ровно то, которое изолировано под шлюз. Стоило ARsim туда сесть, занятость ядра подскакивала до половины и двухмиллисекундный такт плыл. Точечные заплатки на каждый способ запуска не помогали: закроешь один путь, найдётся другой. Помогло только развести всё через cgroup. Шлюз живёт в своей группе, и только этой группе доступно изолированное ядро, а система, сеанс пользователя и контейнеры получают остальные ядра. Проверялось это не чтением конфигов, а попытками посадить работу на ядро цикла всеми известными способами. Все отбиты, занятость ядра упала с 52 до 6,5 процента. Туда же, на изолированное ядро, уводятся прерывания той сетевой карты, на которой висят стойки. Эту карту ядерный драйвер openPOWERLINK забирает себе целиком, штатному сетевому стеку Linux она не видна. Вторая карта это обычная локальная сеть мойки, по ней ARsim и разговаривает со шлюзами по Modbus TCP.

Отдельного ПЛК на этом ПК нет. Логику исполняет ARsim, а со стойками говорит шлюз через управляющий узел открытого стека openPOWERLINK поверх драйвера сетевой карты.

Скрипты, которые всё это держат

Собрать систему один раз на стенде и заставить её жить на объекте без присмотра — разные задачи. Второе решается скриптами.

Развёртывание полностью скриптовое и без интернета: один установщик поднимает любой ПК из комплекта, в котором лежит всё, пакеты ядра, исходники стека с патчами, драйверы под оба семейства карт и службы. Все проверки, которые могут остановить установку, идут до любых изменений. Если включён Secure Boot, установщик останавливается, потому что ядро и драйвер не подписаны. Ядро под изоляцию выбирается по топологии кэша из /sys, а не зашитым числом. Порт под POWERLINK выбирается по PCI-слоту и запоминается вместе с MAC-адресом, и это не мелочь: на машине с шестью одинаковыми портами отдать шине порт локальной сети значит потерять доступ к ПК вместе с самим ПК. Отдельная служба передаёт карту драйверу в правильном порядке, порядок тут важен, ниже сказано почему.

За живучесть отвечают три вещи. Шлюз при потере линка не падает, а перезапускает стек внутри себя и честно отдаёт ПЛК «стойки нет». Сам процесс шлюза держит systemd. И отдельный сторож следит за ARsim: поднимает симулятор, если тот умер, возвращает рабочий загрузчик после переустановки ARsim из Automation Studio, а с недавних пор ещё и проверяет рукопожатием, что его OPC UA-сервер отвечает, а не просто держит порт открытым. Всё это на Bash и Python, ничего особенного, но именно это позволяет поставить мини-ПК на мойку и уехать.

Почему openPOWERLINK не заводится из коробки

Стек упирается в три вещи.

Стек заброшен. Последняя версия, 2.7.2, вышла в 2019 году, под современное ядро Linux 6.x она не собирается, а сообщество на вопросы почти не отвечает.

Под современные сетевые карты в нём нет драйвера. Чтобы выдерживать цикл, стек не пользуется обычным сетевым стеком Linux, а работает с Ethernet-контроллером напрямую, своим драйвером в пространстве ядра. Готовые драйверы есть только под старые чипы Intel и Realtek. I225 и I226, которые сейчас стоят в большинстве мини-ПК, — другое семейство: в Linux его обслуживает драйвер igc, устроен он иначе, и в стеке под него ничего нет.

И ядро ушло вперёд. За годы без поддержки из ядра исчезли или поменялись вызовы, на которых стек написан. В сумме понадобилось десять патчей, килобайт на двадцать: под API ядра 6.x, под убранный struct timespec, под sched_setscheduler, который больше не экспортируется, под виртуальный интерфейс стека, который писал MAC-адрес прямо в поле структуры и получал за это предупреждение ядра при каждой остановке. Ещё два патча закрывали дефекты реального времени в самом стеке, о них ниже, и ещё два касались жизни модуля: выгрузку при живом потоке и утечку потоков ядра, если стек не смог стартовать.

Драйвер под I226

За основу взяли драйвер из самого стека, тот, что когда-то был написан под карту I210, и портировали его на семейство I225/I226. Регистры MAC, DMA, прерываний и часов 1588 у них совпадают, так что таймеры, кольца дескрипторов и три вектора MSI-X перенесены почти дословно: в новом драйвере 3343 строки, и от исходного отличаются несколько сотен. Но в трёх местах карты железно разные, и каждое место стоило отдельного разбора.

Первое, планировщик. У I210 отправка кадра точно по времени держалась на шейпере Qav с шагом 32 наносекунды. У I225/I226 вместо него полноценный планировщик 802.1Qbv в наносекундах: у каждой из четырёх очередей есть «ворота» с временем открытия и закрытия, есть базовое время и длина цикла. И очередь, у которой ворота не запрограммированы, не передаёт вообще ничего, молча, без единой ошибки в логе. Нулевая длина цикла и нулевое базовое время означают «планировщик выключен». Рядом ловушка с размером буферов передачи: значение по умолчанию, с которого стартовал порт, оставляло очередям ноль байт, и карта опять не отправила бы ни кадра. Всё это нашлось ещё до первого запуска на железе, когда драйвер построчно сверяли с эталонным драйвером ядра igc, и в коде теперь стоят прямые предупреждения.

Второе, тайминги. Энергосбережение Ethernet (EEE) отключается до сброса PHY: вход и выход из спящего режима на 100BASE-TX стоят десятки микросекунд, а это прямо внутри двухмиллисекундного цикла. Компенсация задержки PHY берётся из реально согласованной скорости линка, а не из предположения: карта умеет 2,5 Гбит/с, сегмент POWERLINK идёт на 100 Мбит/с, и если скорость не проверять, неверно согласованный линк остаётся невидимым. Есть ещё тонкость с горизонтом планировщика. Он заканчивается текущим циклом Qbv длиной в секунду, и кадр, нацеленный за его границу, уходит сразу, если не пометить его как первый кадр следующего цикла. При цикле в две миллисекунды это ровно один кадр в секунду, и без пометки он уходил бы на полмиллисекунды раньше положенного. Это тоже поймали сверкой с igc, до железа.

Третье, устойчивость к молчащему железу. В драйвере были места, где неотвечающий PHY или зависший аппаратный семафор могли повесить ядро намертво, в том числе при выгрузке модуля. Все такие ожидания ограничены по числу попыток, и каждое пишет предупреждение в лог. А при выгрузке тракт передачи возвращается в состояние после сброса, чтобы карта попадала к штатному igc в том виде, в каком он её ждёт. С I210 на этом попались: после этого драйвера карта оставалась в форсированном режиме, и штатный драйвер потом не поднимал линк.

Два дефекта реального времени в самом стеке

Эти два не про I226, они про сам стек, и нашлись они только на железе, на стенде с картой I210 и настоящей стойкой. Раз в несколько минут цикл вставал ровно на полсекунды, 502–517 миллисекунд, и узел уходил в неактивное состояние. Полсекунды оказались умолчанием стека: после пяти опозданий подряд мастер уходит в PreOperational1 и ждёт там 500 миллисекунд. А сами опоздания рождали два дефекта.

Первый сидел в обработчике таймера драйвера I210. При старте он включал среди причин прерывания ещё и переполнение системных часов карты, а оно случается раз в секунду. Обработчик, увидев этот бит, выходил досрочно, не проверив такт цикла. Такт, совпавший с переполнением, терялся, таймер не перевзводился, и опоздания шли пачкой по пять, ровно порог, после которого сеть вылетает из рабочего режима. Второй дефект это запас на подготовку кадров цикла: в стеке он 150 микросекунд, то есть 7,5 процента от двухмиллисекундного цикла, и на обычном ПК под RT-ядром этого впритык. Поднят до 500. На провод это не влияет, кадры всё равно выпускает карта по аппаратному времени. После обеих правок 44 минуты без единого опоздания, ноль отвалов узла и ноль потерянных импульсов на 224 273 фронтах, снятых перемычкой с выхода стойки на её же вход. До правок было около семнадцати отвалов в час. Обе правки перенесены и в драйвер I226.

Что искали на стенде

Первая проверка была ещё до железа: та самая построчная сверка с igc, тринадцать ошибок. Коммит того дня заканчивается словами: «Builds clean against 6.8.0-rt. Not yet run on hardware — the card goes in tomorrow». На следующий день карту поставили в мини-ПК, и первый же прогон с настоящей стойкой за каплером дал 297 766 циклов без единого пропуска и без единой потери по счётчикам самого каплера.

Четыре вещи, до которых дошли на стенде через ошибки, стоят того, чтобы про них рассказать.

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

Арбитр должен быть чужой. Каплер B&R сам считает потерянные кадры, эти счётчики читаются по SDO, и уговорить их никак нельзя. Если за несколько сотен тысяч циклов прирост ноль, значит, ноль. Второй чужой прибор это отдельный ПК на том же сегменте, который слушает кадры SoC с метками времени ядра. Так отделялись провалы мастера от заминок самого наблюдателя: счётчик циклов у шлюза обязан расти ровно на тридцать тысяч в минуту, и если наблюдатель видит паузу в полсекунды, а счётчик полон, значит, заминка у наблюдателя. Что именно наблюдатель намерил — ниже, в прогонах.

Проверять надо попыткой сломать, а не чтением конфигурации. Показательный случай: если стойку включить после шлюза, драйвер заново запрашивает прерывания, они ложатся на общие ядра с приоритетом по умолчанию, и за пять минут набирается 271 потерянный цикл. Нашли ровно этим тестом, вылечили привязкой прерываний после каждого старта стека, отсюда и порядок запуска в скриптах развёртывания. Приоритеты вообще оказались решающими: потоки прерываний карты 95 и 90, цикловой поток 80, поток событий стека 79. По умолчанию PREEMPT_RT даёт потокам прерываний 50, это ниже потока, который ждёт их события, и одна эта инверсия роняла сеть. Что оказалось ни при чём, тоже проверено приборами: прошивка ни при чём (hwlat, SMI ноль), планировщик ни при чём (cyclictest, максимум 61–72 мкс). А вот nohz_full, который обычно советуют для реального времени, здесь только вредит: стек делает системный вызов каждые две миллисекунды и платит за каждый вход в ядро.

И самое долгое расследование было вообще не про этот код. На втором стенде узел выпадал строго по расписанию: через 10,5 секунды, потом через 12,5, и так по кругу. Когда период ровный, это само по себе подсказка, где-то тикает чей-то десятисекундный таймер. ftrace показал, что таймер карты приходит ровно каждые 2,000 мс, а вот обработчик молчит полмиллисекунды на простом чтении регистра. Маленькая программа, читающая регистр карты из пользовательского пространства, показала зависания по 350–770 микросекунд сериями, причём в те же микросекунды зависала и соседняя Realtek. То есть замирала вся шина PCIe. В каждом таком окне было событие ACPI, и по таблицам DSDT оно вело к встроенной графике. Драйвер i915 усыплял GPU через десять секунд простоя, и каждый такой переход замораживал PCIe за южным мостом на пять миллисекунд. Лечится одним udev-правилом, которое держит GPU в D0. Про это стоит помнить всем, кто делает реальное время на бытовом мини-ПК: виновата может быть вообще не та подсистема, на которую смотришь.

Самое долгое по времени было не написание, а прогоны. Ночные, по восемь часов, на двух разных машинах: 7 ч 47 мин и 13,9 миллиона циклов на мини-ПК с I226, который потом поехал на объект, и 8 ч 05 мин и 14,56 миллиона на втором стенде с I210 после лечения графики. Смотрели три вещи: пропуски кадров по счётчикам каплера, выход интервала между кадрами за пределы цикла и стабильность самого ядра ОС под нагрузкой, ни зависаний, ни утечек, ни деградации таймингов к утру. По итогам ноль пропусков и ноль отвалов узла.

Интервал между кадрами по наблюдателю на проводе держится в 2,00 мс, максимум 2,335 мс, дольше 2,5 мс ни одного; но метку времени ставит ядро обычного ПК, и часть этой дрожи принадлежит самому наблюдателю. Дрожь парная: один интервал длиннее, следующий ровно настолько же короче. Это не заслуга каплера, а свойство мастера. Таймер цикла взводится на часах самой карты как «прошлая цель плюс две миллисекунды», и SoC уходит с карты по аппаратному времени запуска на тех же часах. Сетка на проводе принадлежит карте, программе достаточно приготовить кадры за 500 мкс до срока, тот самый запас, поднятый со 150. Опоздание внутри запаса до провода не доходит, сверх запаса кадр уходит поздно, мастер считает это ошибкой цикла, и пять подряд роняют сеть в PreOperational1. У каплера граница своя: SoC должен прийти в пределах цикла плюс допуск потери SoC, каждое нарушение прибавляет к счётчику восемь, каждый чистый цикл вычитает единицу, порог в конфигурации B&R равен 80. Узел выпадает примерно после десяти опозданий подряд. Этот счётчик шлюз и читает у каплера по SDO, и за все прогоны он остался нулём.

Живая мойка: что стенд поймать не мог

На живой мойке проверялись уже не лампочки, а сигналы, которые должны отрабатывать по логике проекта: расходомер считает, дозатор дозирует, тарификация сходится. С первого выезда не заработало, и причина стоит отдельного рассказа, потому что это ровно та граница, дальше которой симулятором ничего не докажешь.

На стойке в одиннадцатом слоте стоит X20ZF0000, модуль-заглушка, без единого сигнала. Но у заглушки есть адрес на внутренней шине стойки X2X. В Automation Studio для неё нет файла описания, и встроенный openCONFIGURATOR молча выкидывает её из конфигурации сети: получается 23 объекта конфигурации модулей при 24 станциях. А каплер адресует конфигурацию каждого модуля по индексу «0x2100 плюс адрес X2X», и по тем же индексам ссылается раскладка данных в кадрах. В итоге конфигурация двенадцатого модуля легла на адрес заглушки, а всё, что дальше, на чужие модули. Обмен идёт, входы до заглушки совпадают с панелью, а все выходы после неё мёртвые, и энергомонитор в конце стойки отдаёт нули. Со штатным ПЛК эта же стойка работала годами, значит, в его конфигурации каплера заглушка была на месте. Потерялась она именно на пути через openCONFIGURATOR и файл CDC.

Вторая ловушка стоила целого дня. Три исправленных файла конфигурации подряд не дали вообще никакого эффекта. Оказалось, каплер хранит конфигурацию у себя во флеше, а менеджер конфигурации openPOWERLINK перезаливает её только тогда, когда дата и время конфигурации, которые узел сообщает о себе, не совпадают с тем, что ждёт мастер. Дата в правках не менялась, и строка «CFM node 1: result 6» на каждом старте означала не «загружено», а «загружать нечего». Догадки съели день. Помог пробник: прямо на объекте в шлюз было добавлено чтение произвольных объектов узла по SDO с выводом в журнал, и он показал две вещи сразу. На адресе заглушки записана конфигурация соседнего модуля выходов, а дата конфигурации в каплере равна ожидаемой, то есть ни одна правка до него не дошла. Механизм в тот же день был доказан на малой стойке стенда: конфигурация с одной только новой датой прошла путь «записана, сброс узла, рабочий режим», и пробник прочитал из узла новую дату.

Исправление это скрипт, который сверяет число станций по карте с числом объектов в конфигурации, вставляет пропущенную станцию, сдвигает последующие конфигурации и 27 ссылок раскладки и поднимает дату. Проверка «станций по карте столько же, сколько объектов в файле» и «дата новая» занимает минуту и теперь стоит в чек-листе перед любым выездом. Со второго выезда стойка заработала целиком: напряжения фаз 230/229/228 вольт на панели, выходы после заглушки принимают команды, дозаторы дали импульсы, и дальше мойка работала уже на клиентах. Почему стенд это пропустил, тоже понятно: главная стойка на всех стендах была программным симулятором узла, настоящей была только малая стойка, а на ней заглушек нет. Симулятор принимает любую конфигурацию. Настоящий каплер нет.

Уже на работающей мойке всплыли ещё два эффекта, которых на контроллере B&R не бывает, и их полезно знать всем, кто запускает ARsim под Wine. Первый: под нагрузкой на трёх ядрах хозяйства (удалённый рабочий стол, обслуживание USB, опрос HDMI-выхода драйвером графики) OPC UA-сервер внутри ARsim однажды завис. Процесс жив, логика работает, шина чистая, а порт 4840 принимает соединения и молчит, и панели постов теряют связь с ПЛК. Лечится перезапуском ARsim, поэтому сторож теперь проверяет рукопожатие OPC UA, а не только то, что процесс есть. Второй: в проекте есть код, который каждый цикл сначала гасит элементы витрины визуализации, а в конце заполняет их заново. На ПЛК это работает без последствий, визуализация не может вклиниться в цикл задачи. А в ARsim задача это обычный поток Linux, ОС может вытеснить его ровно в этом окне, и элемент на мнемосхеме на секунду пропадает. Гонки внутри цикла, которых на ПЛК не бывает, здесь возможны, и такой код лучше переписать так, чтобы витрина публиковалась одним копированием.

Чего пока нет

Отлажены стойки, где на POWERLINK только ввод-вывод. На старых объектах на той же шине висят ещё и частотные преобразователи, их предстоит поднимать отдельно. Драйвер и конфигурация шины на работающем объекте меняются только через перезагрузку: остановка шлюза на ходу один раз повесила машину намертво, а на стенде это не повторилось. Самые длинные прогоны пока — восемь часов на стенде и неделя на живой мойке без единого сбоя. Многомесячной статистики ещё нет.