Попытка использовать ChatGPT для написания программы на Structured Text для центрального кондиционера с IOLIST на 40 точек дала предсказуемый результат: код компилировался, но содержал выдуманные уставки, перепутанные нормально-замкнутые и нормально-разомкнутые контакты и проигнорированные сигналы. Именно этот опыт стал отправной точкой для разработки PLC ИИ Studio.
Structured Text — один из пяти языков программирования ПЛК по стандарту МЭК 61131-3, внешне похожий на Pascal. На нём пишут прикладные программы для контроллеров ОВЕН, WAGO, Siemens и других. Проблема с языковыми моделями здесь не в незнании синтаксиса — GPT-4o и Claude пишут синтаксически корректный ST. Проблема в том, что модель не обязана разобраться в задаче перед генерацией и никто не проверяет результат после. Именно этот разрыв и закрывает PLC ИИ Studio.
| Шаг конвейера | Кто выполняет | Что проверяется / извлекается |
|---|---|---|
| Разбор IOLIST | Детерминированный парсер | Теги, адреса, типы DI/DO/AI/AO, NC/NO, диапазоны шкалирования |
| Разбор ТЗ | Языковая модель (LLM) | Уставки, алгоритм работы, перечень POU, NC-контакты из текста |
| Технический бриф | Система + инженер | Согласование плана программы до генерации кода |
| Генерация ST-кода | Языковая модель (LLM) | Код на Structured Text по МЭК 61131-3 |
| Верификация кода | Компилятор matiec | Синтаксические и типовые ошибки в ST |
Инструмент построен как инженерный конвейер с несколькими независимыми слоями проверки. На входе — два документа, которые существуют в любом проекте автоматизации: IOLIST (список ввода-вывода в формате Excel, CSV или JSON) и техническое задание (PDF, DOCX, TXT или ZIP-архив проекта). Программа самостоятельно находит строку заголовков в первых 20 строках Excel по ключевым словам TAG, ADDRESS, TYPE, ИИ/AO/DI/DO и разбирает содержимое без ручной настройки. Текст из PDF извлекается через pdfplumber с лимитом 120 000 символов — около 60–80 страниц.
NC/NO-признаки контактов и диапазоны шкалирования аналоговых каналов извлекаются детерминированным парсером без участия ИИ.
Ключевое архитектурное решение: NC/NO-признаки дискретных входов, адреса точек и диапазоны шкалирования аналоговых каналов извлекаются детерминированным парсером без участия языковой модели. IOLIST — таблица с чёткой структурой, и разбирать её нужно точно, а не «приблизительно». ИИ подключается только там, где есть реальная неопределённость: из текста ТЗ он извлекает числовые уставки, пошаговый алгоритм работы установки и перечень необходимых функциональных блоков (POU). При этом модель берёт значения строго из загруженного документа — если в ТЗ написано «защита по перегреву при +85°C», именно это значение попадает в код.
Перед началом генерации система формирует технический бриф — структурированный план программы — и показывает его инженеру. Это позволяет поймать ошибки интерпретации ТЗ до того, как будет написана хоть строка кода. Кириллические имена тегов на этом этапе транслитерируются: переменная «Насос_1» становится «Nasos_1», поскольку языковые модели стабильнее работают с латиницей при генерации идентификаторов.
На выходе конвейер формирует код на Structured Text по МЭК 61131-3, графические схемы SFC, LD и FBD, SCADA-мнемосхему для согласования с заказчиком и пояснительную записку по ГОСТ 21.408-2013. Сгенерированный ST-код проверяется компилятором matiec — открытым компилятором языков МЭК 61131-3 из проекта Beremiz, который транслирует Structured Text в C и выявляет синтаксические и типовые ошибки до передачи результата инженеру.
Весь инструмент работает офлайн как единый.exe под Windows. Данные проекта и технические задания не покидают компьютер; API-ключи к облачным провайдерам, если инженер их использует, хранятся только локально. Автор публикует описание инструмента на этапе тестирования на реальных проектах и запрашивает обратную связь от инженерного сообщества — в первую очередь по слабым местам и нераскрытым сценариям применения.
Подход с разделением детерминированного парсинга и генерации ИИ не уникален для промышленной автоматизации: схожую логику используют инструменты вроде GitHub Copilot Workspace, где модель сначала составляет план изменений, а не сразу пишет код. Однако в сегменте ПЛК-программирования готовых инструментов с верификацией через реальный компилятор практически нет — большинство решений останавливаются на уровне чат-интерфейса поверх общей языковой модели.
