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

В первой статье я рассказывал, как остался один на две сотни моек. Там было про то, почему это вообще получилось. Здесь будет про то, как именно, с конкретикой, которую в комментариях просили.

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

А вот со старыми мойками так не выйдет. У них стойки родные, B&R, и общаются они с контроллером по POWERLINK. Это протокол жёсткого реального времени с циклом в две миллисекунды, и стоял он там не ради красоты: ПЛК на нём считал фронты расходомеров и формировал импульсы дозаторов. Умирает на таких объектах, как правило, именно контроллер, а стойки живут и готовы служить ещё лет десять. Менять их жалко и дорого, покупать контроллер тоже дорого, подержанный через серый импорт стоит от полумиллиона до трёх с половиной миллионов рублей, и это на каждый отказ. Вот про этот случай статья: как поставить вместо контроллера мини-ПК и не тронуть ни стойки, ни сам проект.

В 2000 году я писал на ассемблере софт для проверки приборов спутникового слежения и был уверен, что серьёзные системы делаются только руками. До вайб‑кодинга оставалась четверть века.

Сейчас мне 50. С тех пор я почти всё время писал софт для железа: корабельные системы управления, проверочные комплексы для авионики, теплосчётчики, домофоны, последние годы оборудование для автомоек самообслуживания. Архитектуру своих систем я всегда придумывал сам, и низкий уровень, прошивки, тоже писал сам. А вот дальше начиналась зависимость от людей. Сервер, веб‑интерфейс, документация: под каждую такую часть нужен был отдельный человек, которого ещё надо найти и оплатить, а потом сидеть и ждать. Пока всё это не собрано, твоя архитектура существует на бумаге, и сколько ни говори «я архитектор», показать тебе нечего.

К ИИ я относился так же, как большинство знакомых мне инженеров. Игрушка. Лендинг накидать, стишок написать, в лучшем случае скрипт. Слово «вайб‑кодинг» для меня означало примерно это: человек сам не понимает, что делает, и надеется, что модель как‑нибудь сделает за него. Люди, которых я уважаю, в серьёзные проекты ИИ не пускали, ну и я не пускал. Пробовать я стал от безвыходности: в компании не осталось разработчиков, а объектов на поддержке осталось две сотни. Через ИИ пришлось пропустить вообще всю разработку, включая задачи, за которые раньше взялась бы только команда. И тут выяснилось, что это давно уже не игрушка. Ставишь задачу, задаёшь архитектуру, и он делает так, как сделали бы нормальные программисты.