Как заменить умерший контроллер B&R на мини-ПК: опыт и практика

Когда в условиях санкций из строя выходит промышленный контроллер B&R, а покупка нового оборудования через серый импорт обходится в астрономические суммы, инженерам приходится искать нестандартные выходы. Я столкнулся с масштабной задачей: заменить умершую «голову» на автомойках, полностью сохранив родные стойки X20, проводку и всю периферию, но при этом не переписывая исходный проект автоматизации.

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

Контекст задачи: почему нельзя просто выбросить контроллер

Проекты нашей автоматизации написаны в среде Automation Studio и исполняются на контроллерах B&R. Для новых объектов мы давно используем мини-ПК в паре с модулями на протоколе Modbus TCP, однако на старых объектах ситуация принципиально иная. Там задействованы оригинальные стойки B&R, обменивающиеся данными по шине POWERLINK. Этот протокол жесткого реального времени с двухмиллисекундным циклом выполняет критически важные функции: опрашивает фронты расходомеров и формирует точные импульсы дозаторов химии.

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

Что оставляем, а что меняем в архитектуре

Физическое железо на объектах остается абсолютно нетронутым: силовые шкафы, клеммы, датчики, исполнительные механизмы и фирменные стойки модулей B&R X20 продолжают функционировать. Модификации подвергается исключительно управляющая «голова». Для выполнения логики на обычном ПК я задействую ARsim — официальный и штатный симулятор рантайма от B&R, который умеет обмениваться данными по протоколу Modbus TCP.

Ограничения симулятора и роль шлюзов

У ARsim обнаружились два существенных ограничения. Во-первых, он поддерживает физический ввод-вывод исключительно по Modbus TCP, игнорируя POWERLINK. Во-вторых, этот тридцатидвухразрядный симулятор резервирует буферы под каждую Modbus-станцию. В нашем проекте 2019 года таких устройств насчитывалось свыше десятка, и при подключении уже семи станций адресное пространство исчерпывалось, что приводило к сбою рантайма.

Чтобы обойти эти барьеры, между ARsim и реальными стойками устанавливается промежуточный шлюз реального времени. Благодаря этому вся сложная периферия со стороны проекта выглядит как одна единственная Modbus-станция.

Распределение задач между ПЛК и ПК

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

Именно эти задачи были вынесены в специализированный шлюз, работающий на выделенном ядре процессора с тактом в две миллисекунды. Шлюз обрабатывает 184 сигнала для стоек 2019 года, передавая агрегированные данные в формате Modbus TCP для ARsim. Дополнительный генератор автоматически создает всю конфигурацию и таблицы привязки переменных на основе исходного проекта, исключая ручные ошибки.

Аппаратная часть и операционная система

Для реализации проекта я использовал мини-ПК с несколькими сетевыми портами Intel (на стендах стояли чипы I210, а на реальные объекты отправились машины с шестью портами I226-V). Ключевое требование к процессору — наличие нескольких физических ядер с раздельным кэшем, чтобы выделить одно изолированное ядро исключительно под задачи реального времени.

В качестве операционной системы применяется Ubuntu с кастомным ядром 6.8, пропатченным модулем PREEMPT_RT, повышенной частотой прерываний и жесткой изоляцией процессорных ядер.

Особенности работы ARsim под Wine

Поскольку ARsim является Windows-приложением, на выбранной ОС оно запускается через слой совместимости Wine без использования виртуальных машин. Здесь всплыл любопытный нюанс: симулятор автоматически стремится занять старшее ядро процессора, которое я предварительно зарезервировал под шлюз. Это приводило к скачкам загрузки процессора и деградации двухмиллисекундного цикла.

Проблема была решена с помощью настройки групп ресурсов cgroup. Шлюз получил монопольный доступ к изолированному ядру, тогда как системные процессы и пользовательские сеансы распределились по остальным потокам. В результате загрузка критического ядра упала с 52% до стабильных 6,5%.

Программные трудности с openPOWERLINK и драйвером I226

Открытая реализация стека openPOWERLINK на бумаге идеально подходила для нашей задумки, но на практике столкнулась с устареванием кодовой базы. Версия 2.7.2 вышла в 2019 году, она не собирается на современных ядрах Linux версии 6.x и не содержит встроенных драйверов для современных сетевых контроллеров вроде семейств Intel I225 и I226, которые обслуживаются иным драйвером igc.

Для адаптации стека потребовалось создать десяток патчей общим объемом около двадцати килобайт, исправить устаревшие вызовы API ядра и устранить скрытые дефекты реального времени. За основу нового драйвера был взят старый код для карты I210 и перенесен на чипы I226.

Ключевые доработки сетевого драйвера

Потребовалось переработать планировщик кадров: вместо устаревшего шейпера Qav в новом семействе используется полноценный аппаратный планировщик 802.1Qbv с наносекундными интервалами. Кроме того, была отключена функция энергосбережения Ethernet на физическом уровне, способная вызывать задержки, превышающие длительность двухмиллисекундного цикла.

Третьим важным аспектом стала защита от зависаний при потере связи с периферией: все операции ожидания ответа PHY-чипа получили строгие ограничения по количеству попыток, что исключает зависание ядра операционной системы при выгрузке модуля.

Практическая отладка, тестирование и полевые испытания

Разработка базового кода и патчей заняла около трех-четырех дней, однако процесс комплексного тестирования на стендах потребовал гораздо больше времени. Мы провели серию многочасовых ночных прогонов, фиксируя миллионы циклов обмена данными без единого сбоя. Особое внимание уделялось проверке поведения системы в нештатных ситуациях.

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

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

Итоги и экономическая эффективность

Предложенное решение позволило полностью отказаться от дефицитных и баснословно дорогих контроллеров B&R без необходимости переписывать прикладной код проекта. Сокращение расходов колоссально: стоимость мини-ПК на порядки ниже приобретения подержанного промышленного оборудования через серый импорт.

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