Промышленный GenAI: Как LLM генерирует Structured Text и почему это надо проверять
Шаблоны, рефакторинг, ограничения, риск "уверенной ошибки" и обязательный чек-лист проверки сгенерированного кода
LLM уже добрались до инженерных задач в АСУ ТП: написать шаблон функционального блока, подправить Structured Text, собрать документацию по логике, объяснить чужой код. На фоне дефицита времени это выглядит как подарок. И это действительно полезно — до момента, пока модель не выдает “уверенно неправильное” решение там, где цена ошибки измеряется не багом в интерфейсе, а реальным риском для процесса.
Главная мысль проста: GenAI в промышленной автоматизации — хороший ускоритель, но плохой источник финальной истины.
Короткий ответ
LLM отлично помогает с шаблонами, рефакторингом и документацией ST-кода. Но не может гарантировать корректность safety-логики, учитывать все вендорные нюансы и граничные сценарии. Любой сгенерированный код для ПЛК должен проходить обязательный code review и стендовые проверки.
Что модель умеет и почему это полезно
На рутинных задачах польза заметна сразу. Если нужно набросать каркас функции, привести разрозненный код к единообразному стилю, выделить повторяющиеся участки в подпрограммы или быстро сделать читаемые комментарии — LLM экономит время и снижает порог входа для команды.
Хорошо работает и “обратная” задача: когда есть старый ST-блок без документации, модель может быстро объяснить структуру, входы/выходы и вероятную логику. Это ускоряет онбординг и ревью legacy-проектов.
Отдельный плюс — подготовка рабочей документации: описания для FAT/SAT, черновики release notes, пояснения для эксплуатационщиков. То, что раньше откладывали “на потом”, становится дешевле по времени.
Что модель не умеет (или умеет опасно)
Самая проблемная зона — нюансы конкретного вендора и платформы. LLM может писать синтаксически похожий код, но пропускать ограничения среды, различия по библиотекам, особенности выполнения задач и поведения контроллера при перезапуске.
Вторая зона — safety и межблочные взаимосвязи. Модель может дать “логичную” ветвь условий, которая ломается в редком, но критичном сценарии: например, при одновременном отказе датчика и потере связи. В тексте всё выглядит аккуратно, а в процессе это уже риск.
Третья проблема — “уверенная ошибка”. LLM редко говорит “не знаю” и чаще формирует правдоподобный ответ. Для инженера это коварно: чем аккуратнее написан код, тем выше шанс принять его без достаточной проверки.
Почему code review здесь не формальность
В ИТ ревью часто ловит стиль и архитектуру. В АСУ ТП к этому добавляются режимы процесса, отказоустойчивость, порядок переходов, поведение аварийной логики и последствия для оборудования. Поэтому ревью сгенерированного ST-кода — это не “бюрократия”, а инженерный контроль риска.
Рабочая практика: любой LLM-код проходит минимум два слоя проверки — функциональный (инженер логики) и эксплуатационно-безопасностный (инженер процесса/ответственный за участок). Дальше — стенд и сценарии деградации, а не только “компилируется/не компилируется”.
Пример: промт -> ответ LLM -> что проверить в первую очередь
Ниже упрощенный, но типичный кейс.
1) Промт инженера
Сгенерируй Structured Text для управления насосом P-101.
Условия:
- Запуск по команде StartCmd
- Останов по StopCmd
- Блокировка при LowLevel = TRUE
- Авария при перегрузке MotorOL = TRUE
- После аварии повторный запуск только после ResetCmd
2) Типичный ответ LLM (упрощенно)
IF StopCmd THEN
PumpRun := FALSE;
ELSIF StartCmd AND NOT LowLevel AND NOT MotorOL THEN
PumpRun := TRUE;
END_IF;
IF MotorOL THEN
Alarm := TRUE;
END_IF;
IF ResetCmd THEN
Alarm := FALSE;
END_IF;
3) Что инженер должен проверить в первую очередь
•Латч аварии: в примере PumpRun не принудительно сбрасывается при MotorOL, а Alarm можно снять ResetCmd, даже если причина не устранена.
•Порядок приоритетов: не описано, что делать при одновременных StartCmd и StopCmd.
•Fail-safe поведение: нет явной обработки “плохих/невалидных” входов и потери сигнала датчика уровня.
•Реальный state-machine: логика смешана в IF без формальных состояний (STOP, RUN, TRIP, RESET_WAIT), что усложняет предсказуемость.
•Интеграция с контуром безопасности: не учтены внешние interlock/permissive и требования конкретного объекта.
Именно такие вещи чаще всего “проскальзывают”, если принять код модели за готовое решение.
Как использовать GenAI в ST без самообмана
Лучше всего работает роль “ускорителя первой версии”. Модель делает черновик, инженер превращает его в промышленный код. Если эту роль не путать, выигрыш по времени реальный и устойчивый.
Практически это означает три правила:
1.Давать модели максимально конкретный контекст (вендор, версия среды, режимы, ограничения).
2.Не отправлять в прод код без ревью и стендовых сценариев отказа.
3.Версионировать и трассировать LLM-правки так же, как ручные изменения.
Где уместен СТАБУР
В командах с регулярными доработками PLC/SCADA GenAI полезен как инструмент ускорения рутины, если встроен в дисциплину инженерного цикла. В подходе на базе решений СТАБУР это обычно означает: LLM для черновиков и документации, а финальные решения — через review, тесты и регламентированный релиз.
FAQ
Можно ли использовать LLM для safety-кода?
Можно только как черновик; финальная логика требует формальной инженерной проверки и тестов.
Что выгоднее всего делегировать модели в ST-потоке?
Шаблоны, рефакторинг, комментарии и подготовку документации.
Как снизить риск галлюцинаций?
Давать контекст, ограничивать область задачи и проверять ответ по чек-листу.
Нужен ли отдельный регламент для LLM-кода?
Да, иначе сгенерированные правки будут обходить стандартный процесс контроля изменений.
Можно ли мерить эффект GenAI в деньгах?
Да: через сокращение времени разработки/документирования и снижение ошибок на ранних этапах.
Внутренняя перелинковка
•ChatGPT и LLM для инженера АСУ ТП;