ИИ-ассистенты добрались до ПЛК: читают проекты, пишут ST и сами запускают компиляцию

Программирование промышленных контроллеров долго оставалось в стороне от волны ИИ-ассистентов, которая прошла по Python, C++ и JavaScript. Теперь это меняется. Обзор на Habr фиксирует: появляются специализированные инструменты, которые читают PLC-проекты, объясняют релейную логику на LAD, генерируют код на Structured Text (ST) и в отдельных случаях сами запускают компиляцию. Задача похожа на обычную разработку: есть язык, переменные, условия, таймеры и функциональные блоки. Но на практике всё упирается в нюансы.

Чем ПЛК отличается от обычного кода

Стандарт IEC 61131-3 описывает пять языков: LD (он же LAD), FBD, ST, SFC и IL. Только ST выглядит как привычный текстовый код, он близок к Pascal. Остальные в значительной степени графические: релейная схема или диаграмма функциональных блоков плохо переводятся в последовательность токенов. Для языковой модели это проблема представления данных.

Есть и вторая сложность. Проекты для контроллеров обычно закрыты, лежат в вендорских форматах и средах (TIA Portal, Studio 5000, CODESYS и других), а публичных примеров заметно меньше, чем для веб-разработки. Поэтому модель, которая отлично пишет REST-сервис, может уверенно выдать ST-код с несуществующим блоком или неверной семантикой таймера.

И третья: цена ошибки. Баг в приложении откатывают релизом, а некорректная логика насоса или конвейера может остановить линию или повредить оборудование.

Что инструменты умеют сегодня

Простой чат с моделью («напиши алгоритм управления насосом») работает как отправная точка. Специализированные решения идут дальше, потому что получают доступ к самому проекту. По описанию в обзоре, их возможности выглядят так:

• чтение PLC-проекта: разбор структуры, блоков, тегов и связей между ними;
• объяснение LAD человеческим языком, что полезно при разборе чужого или унаследованного кода;
• генерация кода на ST по текстовому описанию алгоритма;
• запуск компиляции в части инструментов, то есть цикл «написал, собрал, получил ошибки, исправил» без участия человека;
• ограничения: качество сильно зависит от среды, формата проекта и языка, а графические языки поддерживаются хуже текстовых.

Именно замкнутый цикл с компилятором выглядит самым важным шагом. Обратная связь от инструментария снижает долю синтаксических и типовых ошибок. Похожую идею развивали и в исследовательской работе LLM4PLC, где генерацию кода сочетали с проверкой и верификацией. Крупные производители автоматики тоже встраивают генеративные ассистенты в собственные среды разработки. Тот же Siemens вместе с Microsoft анонсировал Industrial Copilot ещё в 2023 году.

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

Куда это движется

Вероятное направление такое: ассистент перестаёт быть генератором фрагментов и становится участником инженерного процесса. Он читает проект целиком, предлагает правки, собирает, прогоняет на симуляции и показывает результат человеку. Главным ограничением остаётся не умение писать код, а проверка соответствия технологическому процессу.

Подробные сравнения конкретных инструментов лежат в оригинальной статье на Habr. Здесь важна общая картина: ПЛК перестаёт быть зоной, куда ИИ не заходит.

Как подойти к этим инструментам на практике

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

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