ИИ в разработке на Python, C++, JavaScript и других языках уже довольно привычное дело. На Хабре об этом много пишут, часто спорят и регулярно обсуждают, как теперь должна выглядеть работа программиста.
Ну а что происходит с программированием ПЛК?
На первый взгляд, задача похожая. Есть язык, переменные, условия, таймеры и функциональные блоки. Почему бы не попросить модель написать алгоритм управления насосом или конвейером?
Попросить уже можно, но пока не все так просто. Появляется все больше специальных инструментов, которые читают PLC-проекты, объясняют LAD, генерируют код на ST и в некоторых случаях сами запускают компиляцию. Но в работе с ними пока хватает своих нюансов.
В этой статье я попытался разобраться, что сегодня представляют собой ИИ-инструменты для работы с кодом ПЛК, что они действительно делают и куда все это движется.
Первые эксперименты с ИИ и ПЛК
Помню, как примерно три года назад наткнулся на один из первых роликов с экспериментами по написанию кода для ПЛК с помощью ИИ. Это был ролик Jakob Sagatowski, в котором он пробовал решать задачи программирования ПЛК с помощью ChatGPT. Просил написать ПИД-регулятор на ST, логику с задержкой и блок для передачи строки по TCP/IP в TwinCAT. Заодно задавал вопросы о языках и средах разработки.
Я тогда еще работал в компании-интеграторе. Мы писали ПО для контроллеров и SCADA-систем и уже сами пробовали экспериментировать с ИИ. Интерес был вполне практический: если модель помогает писать код в других областях, почему бы не попробовать поручить ей часть нашей работы?
Но после того ролика и собственных экспериментов у меня осталось ощущение, что для серьезной работы с ПЛК пока рановато. Получить объяснение или заготовку кода уже было возможно. А вот рассчитывать, что модель разберется в задаче и выдаст результат, который можно спокойно перенести в проект, было рановато. Проверять приходилось многое, а уверенность ответа далеко не всегда помогала.
Универсальные модели того времени были заметно ограничены в объеме контекста, который могли учитывать в одном запросе. С доступными примерами для обучения в нашей области тоже сложнее: исходники промышленных проектов редко публикуют так же свободно, как код на Python или C++.
Да и программирование ПЛК отличается от разработки приложений не только количеством доступных примеров.
К примеру, блок управления насосом живет внутри проекта: где-то объявлены его типы данных, подключена библиотека оборудования и настроены задачи, где-то формируются блокировки и команды с HMI. Программа выполняется циклически, таймеры и функциональные блоки сохраняют состояние между вызовами. Написать похожий на правильный фрагмент - только часть работы. Нужно еще понять, как он будет работать со всем остальным.
Поэтому мне уже тогда казалось, что здесь нужен более предметный подход: обучать модели на примерах из автоматизации, давать им документацию конкретной платформы и доступ к структуре проекта. А затем проверять результат в инженерной среде. Одного знания синтаксиса для этого мало.
От разбора кода к работе с проектом
Первым инструментом с такими возможностями, на который я наткнулся, был PLC Copilot. В тот момент он работал только с проектами для контроллеров Rockwell Automation из Studio 5000. Это был прежде всего ассистент для разбора существующей программы: загружаешь проект, задаешь вопросы по коду, получаешь объяснения и подсказки. Он помогал разобраться в логике, но сам не проходил весь путь от изменения проекта до проверки результата.
Это уже выглядело полезнее обычного разговора с моделью. Не нужно было вручную копировать отдельные сети и пытаться объяснить, как они связаны, инструмент работал с загруженным проектом. Для программы, доставшейся от другого инженера, такая помощь вполне может пригодиться. Особенно если комментарии закончились примерно там же, где началась сложная логика. Однако возможности ПО пока все равно были довольно скромными, а хотелось намного большего: помощи в написании новой логики, внесении изменений и проверке результата.
Я не возвращался к PLC Copilot примерно полгода и только в начале сентября 2026 года решил снова посмотреть, что изменилось. И увидел, что много, о чем только мечтали уже появилось: разработчики добавили поддержку других инженерных сред, заявили генерацию кода и расширили возможности работы с проектом.
Когда же я решил посмотреть, а есть ли у PLC Copilot конкуренты, то обнаружил больше десятка специализированных решений. Причем это уже и самостоятельные приложения, и ИИ-функции в платформах для работы с исходниками, и встроенные помощники от производителей ПЛК.
Что уже умеют ИИ-инструменты для ПЛК
Возможности тоже стали шире. Объяснение существующей логики, поиск связей между блоками и тегами, подготовка документации, генерация ST и преобразование между ST и Ladder - все это встречается в разных инструментах. Некоторые уже подключаются к инженерной среде, вносят изменения в проект, запускают компиляцию и исправляют ошибки по ее результатам. У других заявлена помощь с HMI и конфигурацией оборудования. Набор функций зависит от продукта и поддерживаемой платформы.
Все чаще разработчики позиционируют такие инструменты как агентов. Переход от ассистента к агенту здесь вполне конкретный: от объяснений и подсказок к выполнению цепочки действий - прочитать проект, изменить блок, скомпилировать и исправить найденные ошибки. При этом модель получает обратную связь от настоящей инженерной среды. Хотя успешная компиляция, конечно, еще не означает, что конвейер поедет куда нужно.
Я выбрал пять примеров, чтобы показать разные подходы: анализ загруженного проекта, работу через репозиторий, мост к IDE и собственные решения производителей инженерных сред.
PLC Copilot
У PLC Copilot разработчики сейчас заявляют поддержку Rockwell Studio 5000, Siemens TIA Portal и AutomationDirect Productivity Suite. CODESYS на странице продукта находится в списке ожидания.
Возможности включают объяснение логики, поиск связей между тегами, подготовку документации и генерацию кода для импорта. Продукт позиционируется как настольное Windows-приложение. Сгенерированный код можно импортировать в проект, предварительно проверив его.
Наиболее понятный сценарий - разобраться в программе, которую писал кто-то другой. Найти условия пуска, связанные блокировки, места использования сигналов и собрать описание алгоритма. В автоматизации это вполне самостоятельная задача, иногда даже более трудоемкая, чем написать новый блок.
По опубликованным тарифам, Pro стоит $99 в месяц, Ultra - $499 в месяц при помесячной оплате. Для Enterprise цену рассчитывают индивидуально. Есть и бессрочная лицензия для локального или изолированного развертывания: $720 за устройство; после первого года обновления можно продолжить с дополнительным пакетом поддержки за $270 в год на устройство. Бесплатный Trial рассчитан на 30 дней и включает 100 кредитов, стандартную модель и работу с одним проектом.
Copia AI и Copilot
Copia AI использует проекты из Copia Source Control и резервных копий DeviceLink. Производитель заявляет объяснение и документирование кода, генерацию фрагментов и преобразование между LAD и ST.
В FAQ Copilot указаны Studio 5000 и TIA Portal, а также LAD и ST. Поддержку форматов другими продуктами Copia не стоит автоматически считать поддержкой этих форматов ИИ-помощником.
Главное отличие подхода - источник контекста. ИИ работает с программой из системы управления исходниками. Можно, например, подготовить описание выбранной версии и затем сопоставить его с изменением.
Публичного тарифа для Copia AI/Copilot нет. В документации для подключения Copilot к подписке и получения условий пробного доступа предлагают обратиться к менеджеру Copia. Продолжительность и ограничения такого доступа публично не указаны. Также можно запросить демонстрацию.
PLC Assist
PLC Assist делает акцент на Structured Text и обратной связи от компилятора. По документации, поддерживаются CODESYS V3.5 SP18+ и TwinCAT 3.1+. TIA Portal пока указан как сoming soon.
К IDE подключается локальный мост: Python-скрипт внутри CODESYS или отдельное Windows-приложение для TwinCAT. Он читает структуру проекта, применяет изменения и передает результаты компиляции облачному агенту. Необходимые фрагменты кода, как указывает разработчик, отправляются ИИ-провайдеру.
Также заявлены показ изменений и исправление ошибок по диагностике штатного компилятора.
Это уже довольно близко к привычной работе программиста с агентом: добавить выход в блок, учесть существующий интерфейс, собрать проект и исправить возникшие ошибки.
При этом успешная сборка подтверждает только то, что проверила среда. Правильно ли работает новый диагностический сигнал, придется выяснять отдельно.
На странице тарифов указаны Pro за €24 в месяц и Power за €49 в месяц. Power дает в 2,5 раза больший объем использования ИИ. Есть бесплатный тариф Trial с ограниченным использованием: доступны генерация и проверка кода, подключение к CODESYS и TwinCAT и документация библиотек. Срок пробного доступа и точный лимит не указаны.
Siemens Eigen Engineering Agent
У Siemens есть собственный Eigen Engineering Agent. Сейчас он доступен для TIA Portal V19, V20 и V21.
Агент может генерировать PLC-код, создавать HMI и конфигурировать устройства с учетом проекта. Также заявлены чтение электрических схем в XML и AML и генерация структуры проекта по описанию машины.
То есть Siemens смотрит шире отдельной функции: агент должен работать со связанными инженерными данными. Описание станции может стать основой для программы, тегов и конфигурации.
На мой взгляд, собственная объектная модель IDE дает производителю хорошую основу для такой интеграции. Но качество решения конкретной задачи все равно нужно проверять на проекте.
Годовая подписка стоит $2100 (!) за одно лицензионное место без учета возможных налогов. Лицензию можно назначить трем пользователям, но одновременно пользоваться ей может только один. Есть бесплатный пробный период на один месяц; после него действует годовая подписка.
Beckhoff TwinCAT 3 CoAgent for Engineering
Beckhoff TE1700 описывается как помощник для PLC-разработки, конфигурации I/O и создания HMI. Заявлены предложения с учетом структуры проекта и доступ к документации Beckhoff Information System.
Идея вполне инженерная: связать описание задачи с существующей программой и справкой производителя. Например, предложить изменение с учетом уже используемой библиотеки и показать, на каком описании блока основано предложение.
Однако на проверенной странице продукта указан статус product announcement, а предполагаемый срок выхода предлагается уточнять у Beckhoff. Поэтому пока это пример заявленного направления развития, а не подтверждение доступности.
Но этими пятью инструментами, конечно, все не ограничивается. Есть и другие, например: Factory Agent от Software Defined Automation, A-B Copilot, Plaxio, FactoryTalk Design Studio Copilot от Rockwell Automation. По набору возможностей они во многом похожи на рассмотренные выше: разбор логики, подготовка документации, помощь с написанием кода. Какие именно функции доступны, зависит от продукта и поддерживаемой среды.
Что находится за окном чата
Снаружи многие такие продукты похожи: проект, поле для запроса, ответ помощника. Но практическая ценность определяется тем, что происходит между этими элементами.
Если обобщить рассмотренные подходы, получится четыре части. Их конкретная реализация у производителей может отличаться.
Первая читает проект. Она извлекает блоки, сети, переменные, типы, вызовы и доступную конфигурацию. Для текста ST это одна задача, для графического LAD или FBD - другая.
Вторая подбирает контекст. Если вопрос касается одного клапана, нужно найти его блок, вызывающую программу, тип данных и документацию библиотеки. Просто передать модели побольше текста - не всегда хороший способ помочь ей разобраться.
Здесь могут использоваться поиск по исходникам, граф зависимостей и поиск по документации. Один из подходов называется RAG: вместе с вопросом модель получает найденные материалы.
Третья часть превращает ответ в изменение инженерного объекта или файл импорта. При этом нужно сохранить структуру проекта и показать, что именно будет изменено.
Четвертая запускает проверки и возвращает результат. Сначала это формат и компиляция, затем тесты блоков и симуляция, если инструмент умеет с ними работать.
Для инженера полезный результат выглядит примерно так: вот изменение, вот версия проекта, вот сообщения компилятора, вот выполненные сценарии. Фраза «я все внимательно проверил» может прилагаться, но заменять этот набор не должна.
Почему здесь пока хватает сложностей
Промышленные проекты редко лежат на GitHub
В программе машины могут находиться знания о технологии, оборудовании и процессах заказчика. Просто выложить такой проект в открытый доступ вместе с библиотеками и документацией предприятия обычно нельзя.
Вообще ограниченность публичных данных для обучения моделей программированию ПЛК - тема известная. Например, авторы исследования об обучении ИИ писать код на ST тоже отмечают нехватку открытых примеров и рассматривают дообучение моделей с обратной связью от компилятора.
Для разработчиков инструментов задача понятна: дополнять знания модели документацией и контекстом проекта. Но даже внутри проекта не все одинаково надежно. Комментарий мог остаться от предыдущей версии алгоритма, а название переменной - от оборудования, которое давно заменили.
ST бывает разным
Надпись «поддерживает Structured Text» еще мало говорит о совместимости с конкретным проектом. Важны расширения языка, типы, библиотеки, версия среды и целевая платформа.
Допустим, ИИ предложил вызвать блок управления приводом. Название выглядит вполне убедительно. Осталось выяснить, существует ли такой блок в установленной библиотеке.
Если не существует - это сравнительно удобная ошибка. Компилятор, скорее всего, поможет ее обнаружить. Сложнее, если блок существует, вызов допустим, но модель неверно поняла назначение входа или условия выполнения команды.
Поэтому одного запроса «напиши код для Siemens» мало. Модели нужно указать версию TIA Portal, модель ПЛК и библиотеки, которые используются в проекте. Иначе она может предложить функции или блоки, которых в этом проекте нет.
Ladder Logic нужно прочитать и собрать обратно
ST можно передать как текст. LAD и FBD содержат граф связей: ветвления, соединения, параметры блоков и порядок исполнения, определяемый средой.
На скриншоте часть этой информации может отсутствовать. Соседняя сеть не попала в кадр, переменная объявлена в другом месте, вызов программы вообще находится на другом экране. Поэтому объяснение картинки и анализ структурированного экспорта дают разные возможности.
А затем результат нужно вернуть в IDE. Список инструкций сам по себе еще не становится графической программой, которую среда сможет импортировать и отобразить.
При преобразовании LAD в ST и обратно нужно проверять сохранение поведения, включая состояние блоков и порядок вычислений. Совпадение названий переменных здесь слишком слабый критерий.
Программа не знает всей установки
По коду можно увидеть, что сигнал используется как разрешение пуска. Но из одного имени переменной не всегда понятно, какой датчик за ним стоит, как он подключен и что должно происходить при потере связи.
Нужны электрическая схема, перечень I/O, описание алгоритма и требования к режимам работы. Если эти материалы противоречат друг другу, инструмент должен заметить противоречие.
Например, в описании требуется ручной сброс аварии, а существующий код снимает ее автоматически после восстановления сигнала. Объяснить текущее поведение можно по программе. Решить, каким оно должно стать, придется по требованиям.
Уверенность модели этот спор не разрешает.
Компиляция не проверяет технологический процесс
Компилятор проверяет программу в пределах своих возможностей. Он не знает, разрешен ли повторный пуск после восстановления питания или как должна вести себя установка при исчезновении датчика.
Для проверки блока можно задать последовательности входов и наблюдать выходы и состояния. Для оборудования потребуется учитывать ответ объекта: команда меняет положение механизма, положение меняет сигнал датчика, сигнал влияет на следующую команду.
Успешная компиляция еще не означает, что программа правильно управляет оборудованием. Сгенерированный код нужно проверять в штатных и аварийных режимах. При этом важно понимать, какие ситуации проверены, а какие пока остались за пределами тестов.
Где работает сама модель
Фраза «работает локально» требует уточнения. На компьютере могут находиться интерфейс, мост к IDE, проект или сама модель. Это разные части системы.
В PLC Assist документация прямо описывает передачу необходимых фрагментов ИИ-провайдеру. Поэтому перед выбором решения стоит выяснить, что покидает рабочую станцию, где хранится история и какие компоненты требуют внешнего соединения.
Для изолированной площадки это вполне практический вопрос. Если облачный запрос невозможен, модель, поиск по документации и инструменты проверки должны работать внутри доступной инфраструктуры.
Что можно делать уже сейчас
Ограничений пока хватает, но практические задачи для таких инструментов уже есть. Если собрать возможности рассмотренных продуктов, получится примерно такой список. Конечно, конкретный набор зависит от инструмента и поддерживаемой среды.
Разбираться в существующей программе. Получать объяснения логики, находить условия пуска и блокировки, искать связи между тегами и блоками. Особенно полезно, когда проект достался от другого инженера.
Готовить документацию. Составлять описания блоков и алгоритмов, добавлять комментарии и собирать материалы для передачи проекта.
Писать новую логику. Получать заготовки на ST и других поддерживаемых языках, а в некоторых продуктах — преобразовывать Ladder в ST и обратно. Результат затем проверять в своей среде.
Вносить изменения и исправлять ошибки компиляции. Инструменты с подключением к IDE могут менять проект, запускать сборку и использовать сообщения компилятора для следующей попытки.
Помогать с HMI и конфигурацией оборудования. Такая поддержка уже выходит за пределы написания PLC-кода, хотя пока встречается лишь в части решений.
В ближайшем будущем я ожидаю более тесной связи этих функций: изменение блока будет сопровождаться обновлением связанных тегов, HMI и документации. Еще одно интересное направление - автоматическая подготовка тестовых сценариев и запуск симуляции, чтобы помощник мог проверить поведение программы и использовать результаты для исправлений.
А когда это сможет обычный универсальный агент
После такой подборки возникает вопрос: сколько времени пройдет, прежде чем агент вроде Codex или Claude Code получит доступ к инженерной среде и сможет выполнять те же действия? А это точно произойдет, я уверен.
Для такого подключения уже есть готовые механизмы. Например, TIA Portal Openness - интерфейс, через который другая программа может работать с TIA Portal. Он позволяет, в частности, запустить компиляцию и получить список ошибок. На этой основе можно подключить ИИ-агента, который будет запускать компиляцию после своих изменений и исправлять код по замечаниям компилятора.
Возможный путь - адаптер, который предоставляет агенту понятные операции: прочитать блок, найти ссылки, подготовить изменение, скомпилировать. Это вариант архитектуры, а не утверждение, что все перечисленные среды уже штатно подключаются к универсальным агентам.
Для предоставления операций можно использовать, например, MCP (Model Context Protocol). Он описывает взаимодействие ИИ-приложений с внешними инструментами и данными. Но адаптер все равно должен знать API конкретной IDE, ограничения и форматы.
И у CODESYS такой инструмент уже есть - официальный CODESYS Development System MCP Server. Через него ИИ может читать проект, создавать и изменять блоки и типы данных на ST, запускать компиляцию, получать сообщения об ошибках и обращаться к документации библиотек. Кроме того, производитель уже сообщает об успешном подключении Claude Desktop.
Получается достаточно понятная схема: агент планирует работу, адаптер выполняет операции в среде, компилятор и тесты возвращают результаты, инженер оценивает изменение.
Куда все это идет
Думаю, возможности универсальных и специализированных инструментов будут сближаться. А конкуренция постепенно сместится к качеству интеграций и проверки.
Сценарий типа «вставь ST в чат и получи другой ST» универсальному инструменту сравнительно легко воспроизвести. Гораздо больше работы находится в чтении разных версий проектов, сохранении графических сетей, правильном использовании библиотек и проверке изменений.
Производители IDE могут развивать встроенных агентов вокруг собственных объектов. Независимые разработчики - связывать несколько платформ, репозитории и документацию предприятия. Универсальные агенты - использовать доступные инженерные адаптеры. Все это вполне может существовать одновременно.
Поэтому я бы не ставил срок, через который отдельные продукты для ПЛК станут не нужны. Часть их функций может превратиться в интеграции для разных моделей. Но работа с инженерными форматами, библиотеками и испытаниями останется.
Меняться будет и роль инженера. Больше внимания придется уделять постановке алгоритма, выбору контекста, проверке изменений и воспроизводимым испытаниям. Знание технологии здесь особенно полезно: оно позволяет заметить проблему, которую компилятор не увидит.
В своей статье о Modbus-клиенте я уже писал, что ИИ помог сделать приложение, но инженерные сценарии все равно пришлось объяснять и проверять самому. С PLC-кодом логика похожая. Просто вокруг программы еще больше контекста, а результат нужно оценивать по поведению оборудования.
ИИ уже добрался до ПЛК. Теперь интересно посмотреть, насколько хорошо он освоит ту часть работы, которую обычно называют коротким словом «наладка».
В Telegram-канале «Автоматизаторы» я пишу о промышленной автоматизации, инженерном ПО и подобных инструментах. Если тема вам близка - присоединяйтесь.
