Как составлять промпты для ИИ при программировании ПЛК с использованием концепций управления для Yaga

Эффективное использование ИИ для программирования ПЛК требует структурированных концепций управления, а не общих запросов. Когда инженеры предоставляют явные карты ввода/вывода, условия разрешения (permissives), блокировки, состояния последовательностей и условия возникновения неисправностей, Yaga может генерировать каркас лестничной логики, который значительно проще валидировать в среде симуляции OLLA Lab.

ИИ терпит неудачу в работе с ПЛК не потому, что он «плохо пишет код». Он терпит неудачу, потому что лестничная логика — это не просто генерация кода; это детерминированное поведение системы управления с учетом ограничений, порядка сканирования и нештатных состояний. Это различие часто упускается из виду.

В ходе недавнего внутреннего бета-тестирования Yaga Assistant в OLLA Lab промпты, включающие словарь тегов, определенное безопасное состояние и как минимум одну явную блокировку, позволили получить пригодный для симуляции каркас с первой попытки в 22 из 24 задач (91,7%), в то время как общие промпты, такие как «напиши последовательность работы насоса», требовали серьезной корректировки в 17 из 24 задач (70,8%) перед началом симуляции. Методология: n=48 запусков промптов-задач для упражнений с насосом, смесителем, конвейером и уровнем в резервуаре; базовый компаратор = общий промпт на естественном языке против структурированного промпта на основе концепции управления; временной интервал = период внутреннего бета-тестирования, февраль–март 2026 года. Это подтверждает один узкий тезис: структура промпта сильно влияет на пригодность результата с первой попытки для симуляции. Это не доказывает пригодность для внедрения на объекте, достаточность мер безопасности или готовность к промышленной эксплуатации.

В автоматизации промпт-инжиниринг следует определять узко: как систематический перевод механических ограничений, карт ввода/вывода и блокировок безопасности в машиночитаемые параметры, чтобы агент ИИ мог генерировать синтаксически корректный, тестируемый каркас. Это полезный инструмент, а не замена инженерному суждению. OLLA Lab здесь важна как цикл валидации, а не как «разрешение на использование».

Общие LLM терпят неудачу при работе с лестничной логикой, потому что они предсказывают правдоподобные последовательности токенов, в то время как ПЛК выполняют детерминированную логику сканирования на основе состояний входов и выходов. Языковая модель видит непрерывность текста; контроллер видит порядок вычисления, биты памяти, условия фронтов и состояние устройства.

Лестничная логика также пространственна. Параллельные ветви, цепи самоподхвата, цепочки разрешений и взаимоисключающие состояния несут смысл через структуру, а не только через слова. Универсальная LLM склонна линеаризовать эту структуру в текст и может потерять логику выполнения в процессе. Это одна из причин, почему сгенерированная ИИ лестничная логика может выглядеть компетентной, но вести себя плохо.

Второй режим отказа — слабая осведомленность о цикле сканирования. Логика ПЛК вычисляется многократно, и выходы могут быть записаны, сброшены или переопределены в рамках одного сканирования в зависимости от структуры программы. Без явных ограничений LLM может сгенерировать:

• дублирующую запись в одну и ту же выходную катушку,
• отсутствие поведения «однократного импульса» (one-shot),
• состязания (race conditions) между автоматическим и ручным режимами,
• таймеры с неясными условиями сброса,
• аналоговые пороги без гистерезиса или обработки ошибок,
• блокировки, которые присутствуют в комментариях, но не в исполняемой логике.

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

Это ограничение в целом согласуется с литературой по рассуждениям LLM и надежности кода. Опубликованные работы в области программного обеспечения и встроенных систем показывают, что качество вывода снижается, когда задачи требуют отслеживания постоянного состояния, пространственного мышления или точного соблюдения ограничений, а не простого завершения паттернов (Bubeck et al., 2023; Huang & Chang, 2023). Программирование ПЛК особенно беспощадно ко всем трем аспектам.

Промпт для автоматизации промышленного уровня — это компактная функциональная спецификация. Он должен сообщать модели, что представляет собой машина, что означает «безопасно», какие устройства существуют, какие условия должны быть истинными до начала действий и как следует обрабатывать сбои. Если промпт не может поддержать базовый обзор функциональной спецификации проекта (FDS), он, вероятно, слишком расплывчат для надежной генерации лестничной логики.

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

3 столпа промпта для автоматизации

#### 1. Контекст и цель

Укажите машину или технологический узел, цель работы и безопасное состояние.

Включите:

• тип оборудования,
• режим работы,
• цель запуска/остановки,
• условие безопасного отключения,
• ожидание при нештатном состоянии.

Пример:

• «Одиночный перекачивающий насос наполняет дневной резервуар».
• «Безопасное состояние — насос выключен, выходной клапан закрыт».
• «Если датчик уровня неисправен, запретить автоматический запуск».

#### 2. Словарь ввода/вывода и тегов

Определите теги явно. ИИ работает лучше, когда именование однозначно и типизировано.

Включите:

• цифровые входы,
• цифровые выходы,
• аналоговые входы,
• аналоговые выходы (если применимо),
• биты внутренней памяти,
• таймеры и счетчики,
• биты аварий или неисправностей.

Пример:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

Дисциплина именования — это не косметический вопрос. Это разница между отслеживаемой логикой и затратами на отладку.

#### 3. Разрешения и блокировки

Определите, что должно быть истинным до того, как действие может произойти, и что заставляет действие остановиться.

Включите:

• разрешения (permissives),
• аварийные отключения (trips),
• ограничения режимов,
• требования к обратной связи,
• поведение при тайм-ауте,
• условия аварий.

Пример:

• Насос может запуститься, только если `DI_EStop_OK = TRUE`
• Насос может запуститься, только если `AI_Tank_Level_Pct < 80`
• Насос должен остановиться, если `AI_Tank_Level_Pct >= 95`
• Вызвать аварию, если команда на работу есть, а обратной связи по работе нет в течение 3 секунд

Именно здесь многие промпты терпят крах. Инженеры часто указывают «счастливый путь» и опускают причины, по которым машина должна отказаться двигаться. Реальные установки проводят много времени в нештатных условиях.

Для промптов ИИ концепция управления должна определяться как минимальная функциональная спецификация, необходимая для генерации тестируемого каркаса управления. Это не маркетинговая фраза и не расплывчатое описание дизайна. Операционно она должна содержать те же основные поведения, которые инженер по автоматизации ожидает в документе типа FDS:

• начальное состояние,
• режимы работы,
• последовательность операций,
• разрешения,
• блокировки,
• аварии и отключения,
• реакции на сбои,
• поведение при сбросе,
• действия оператора,
• критерии успеха.

Это определение ограничено инженерными наблюдаемыми величинами. Если промпт не говорит модели, что процесс должен делать, когда датчик выходит из строя, крышка открывается, уровень превышает порог или обратная связь никогда не приходит, то этот промпт не является концепцией управления.

Эта формулировка согласуется с устоявшейся практикой промышленной документации. IEC 61131-3 регулирует языки программирования ПЛК, но хорошая лестничная логика все равно зависит от ясности функционала на ранних этапах. Стандарты не спасают при расплывчатых намерениях.

Полезное заблуждение, от которого пора отказаться

Промпт-инжиниринг в автоматизации — это не про то, чтобы сделать ИИ более креативным. Это про то, чтобы сделать спецификацию менее двусмысленной.

Самый эффективный способ давать промпты Yaga — это предоставить ограниченный, многоразовый шаблон. Модели нужно сообщить роль, цель процесса, теги, последовательность, разрешения, блокировки и ожидаемый формат вывода. Если что-то из этого оставить неявным, модель может начать импровизировать.

Рекомендуемый шаблон промпта для Yaga

Действуй как ассистент по лестничной логике IEC 61131-3.

Цель: Создать каркас лестничной логики для следующей задачи управления.

Описание системы: - Оборудование: [машина/технологический узел] - Цель работы: [что система должна делать] - Безопасное состояние: [какие выходы/состояния должны быть истинными при остановке или сбое]

Словарь ввода/вывода и тегов: Цифровые входы: - [тег]: [описание] - [тег]: [описание]

Цифровые выходы: - [тег]: [описание]

Аналоговые входы: - [тег]: [описание и инженерные единицы]

Внутренние биты / Таймеры / Счетчики: - [тег]: [назначение]

Режимы работы:

• [Авто / Ручной / Обслуживание]
• [правила режима]

Последовательность операций:

Разрешения (Permissives):

• [условие, необходимое перед запуском]
• [условие, необходимое перед переходом]

Блокировки / Аварийные отключения:

• [условие, которое должно остановить или запретить работу]
• [условие неисправности и реакция]

Аварии:

• [условие аварии]
• [условие тайм-аута]

Правила сброса / восстановления:

• [требование ручного сброса]
• [правило автосброса, если разрешено]

Требования к выводу:

• Используй четкую структуру лестничной логики по ступеням (rung-by-rung)
• Не записывай в одну и ту же выходную катушку в нескольких конфликтующих местах
• Используй именованные внутренние биты для состояний последовательности, где это необходимо
• Включи комментарии для каждой ступени
• Явно укажи допущения

Этот шаблон не гарантирует правильную логику. Он делает кое-что более полезное: он делает ошибки видимыми раньше.

1. [шаг 1]
2. [шаг 2]
3. [шаг 3]

Младший промпт против старшего промпта

| Стиль промпта | Пример | Вероятный результат | |---|---|---| | Младший промпт | «Сделай лестничную диаграмму, которая включает смеситель на 10 секунд, когда я нажимаю старт». | Двусмысленное поведение при остановке, отсутствие блокировки крышки, неясная логика сброса, слабая структура тегов | | Старший промпт | «Действуй как программист IEC 61131-3. Создай каркас лестничной логики для смесителя. Входы: `PB_Start` (НО), `PB_Stop` (НЗ), `LS_LidClosed`, `EStop_OK`. Выход: `MTR_Mixer`. Блокировка: смеситель не может работать, если крышка не закрыта и E-stop не в порядке. Используй TON для 10-секундного цикла работы. Остановись немедленно при открытии крышки или команде стоп. Безопасное состояние = двигатель выключен. Предоставь комментарии к ступеням и укажи допущения». | Тестируемая база с явными разрешениями, более безопасное поведение при остановке, более четкий путь симуляции |

Разница не в красноречии. Разница в плотности ограничений.

Хороший промпт для ПЛК должен определять машину как систему с состояниями, а не как словесную задачу. Прежде чем Yaga напишет хоть одну ступень, промпт уже должен отвечать на шесть инженерных вопросов.

1. Что это за система?

Определите оборудование, границы процесса и предполагаемую работу.

Пример:

• «Дуплексная насосная станция с ведущим/ведомым насосом, аварийной сигнализацией высокого уровня и чередованием».

2. Что такое «правильное» поведение?

Определите критерий успеха работы в наблюдаемых терминах.

Пример:

• «В автоматическом режиме ведущий насос запускается при уровне 70% в резервуаре и останавливается при 30%; ведомый насос запускается при 90%; оба останавливаются при E-stop или перегрузке двигателя».

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

3. Какие теги и типы сигналов используются?

Перечислите теги, направление сигнала и единицы измерения.

Пример:

• `AI_WetWell_Level_Pct` = аналоговый вход, проценты
• `DI_P1_OL_Trip` = цифровой вход, срабатывание защиты от перегрузки
• `DO_P1_RunCmd` = цифровой выход

4. Какие нештатные условия существуют?

Определите сбои, недопустимые состояния и реакции на неисправности.

Пример:

• плохое качество сигнала датчика уровня,
• отсутствие обратной связи по работе после команды,
• активны обе защиты от перегрузки,
• E-stop не в порядке,
• конфликт переключателя HOA (ручной/выкл/авто).

5. Что никогда не должно происходить?

Явно укажите запрещенное поведение.

Пример:

• «Никогда не подавать команду на оба насоса в логике ручного чередования».
• «Не выполнять автозапуск после сброса перегрузки без действий оператора».
• «Не запускать смеситель с открытой крышкой».

6. Какие допущения допустимы?

Требуйте от ИИ декларировать допущения, а не скрывать их.

Пример:

• «Предполагать, что кнопка стоп — это исправный НЗ контакт, если не указано иное».
• «Предполагать, что аналоговое масштабирование уже выполнено выше по потоку».

Скрытые допущения — частый источник слабой лестничной логики, сгенерированной ИИ.

OLLA Lab валидирует логику, сгенерированную ИИ, помещая ее в среду симуляции, где входы, выходы, переменные и поведение оборудования могут наблюдаться и изменяться до того, как будет рассмотрено какое-либо реальное внедрение. Это делает ее циклом валидации с контролируемым риском, а не оракулом.

Редактор лестничной логики предоставляет поверхность для логики. Режим симуляции обеспечивает выполнение. Панель переменных обеспечивает наблюдаемость тегов, состояний ввода/вывода, аналоговых значений и переменных управления. Вместе они позволяют инженеру проверить, ведет ли себя сгенерированная логика так, как указано, при изменении условий.

На практике это означает, что вы можете:

• переключать цифровые входы,
• принудительно вызывать условия неисправности,
• проверять реакцию выходов,
• наблюдать за изменением состояния таймеров и внутренних битов,
• сравнивать состояние лестничной логики с поведением симулируемого оборудования,
• пересматривать логику после неудачного теста.

Валидация — это не скриншот правильно выглядящей ступени. Валидация — это последовательность опровергнутых допущений, за которыми следует более строгая логика.

Как выглядит цикл генерации-валидации

1. Генерация каркаса с помощью Yaga Используйте структурированный промпт на основе концепции управления.
2. Проверка сгенерированной лестничной логики Проверьте имена тегов, принадлежность выходов, структуру последовательности и размещение блокировок.
3. Запуск логики в симуляции Начните с номинальных условий.
4. Внедрение нештатных условий Принудительно вызовите потерю датчика, неверные разрешения, состояния открытой крышки, срабатывание перегрузки или случаи тайм-аута.
5. Наблюдение за тем, безопасно ли логика терпит неудачу Подтвердите безопасную остановку, фиксацию аварии, запрет перезапуска или удержание состояния, как требуется.
6. Пересмотр и повторное тестирование Уточните промпт или отредактируйте лестничную логику напрямую.

Именно здесь OLLA Lab становится операционно полезной. Она дает инженерам место для репетиции задач с высоким риском, для которых реальные системы — плохие учителя.

Вы проверяете это, определяя случаи неисправностей до того, как довериться номинальной последовательности. Процедура лестничной логики, которая работает только тогда, когда каждый сигнал ведет себя идеально, не валидирована; она просто не подвергалась испытаниям.

Как минимум, протестируйте эти категории в симуляции.

Неисправности целостности входов

• датчик «залип» в высоком состоянии,
• датчик «залип» в низком состоянии,
• передатчик вне диапазона,
• плохое аналоговое значение,
• отсутствие обратной связи после команды.

Отказы блокировок

• E-stop не в порядке,
• ограждение или крышка открыты,
• разрешение потеряно во время работы,
• сработала защита от перегрузки,
• подтверждение клапана не получено.

Неисправности последовательности

• таймер никогда не сбрасывается,
• бит состояния остается зафиксированным (latched),
• перекрытие команд ручного и автоматического режимов,
• перезапуск происходит после аварии без сброса,
• выход остается под напряжением после пути остановки.

Аналоговые и ПИД-связанные неисправности

• переменная процесса превышает порог отключения,
• отсутствует аналоговый гистерезис (deadband),
• дребезг аварии около порога,
• выход контроллера насыщается,
• переключение режимов вызывает скачок.

Наличие аналоговых инструментов и ПИД-панелей в OLLA Lab здесь важно, потому что многие примеры ИИ остаются в ловушке дискретной логики. Реальное управление процессом обычно таковым не является. Насосная станция, приточная установка, тепловой контур или дозирующая установка часто включают пороги, задержки, гистерезис и поведение, зависящее от режима.

Проработанный пример должен показать перевод от намерения процесса к машиночитаемым ограничениям. Ниже приведен компактный пример смесителя, подходящий для Yaga.

Пример структурированного промпта

Действуй как ассистент по лестничной логике IEC 61131-3.

Описание системы: - Оборудование: Смеситель партий - Цель работы: Запустить смеситель на 10 секунд после команды старта оператора - Безопасное состояние: Двигатель смесителя выключается немедленно при стопе, потере E-stop или открытии крышки

Словарь ввода/вывода и тегов: Цифровые входы: - DI_PB_Start: Кнопка старта, нормально открытая - DI_PB_Stop: Кнопка стопа, нормально закрытая - DI_Lid_Closed: Подтверждение закрытия крышки - DI_EStop_OK: E-stop в порядке

Цифровые выходы: - DO_Mixer_Run: Команда на работу двигателя смесителя

Внутренние биты / Таймеры: - M_Mix_Cycle_Active: Фиксация активного цикла смешивания - T_Mix_Run: Таймер TON на 10 секунд

Последовательность операций:

Разрешения:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop в порядке

Блокировки / Аварийные отключения:

• Если крышка открывается во время работы, немедленно обесточить DO_Mixer_Run
• Если E-stop не в порядке, немедленно обесточить DO_Mixer_Run

Требования к выводу:

• Предоставить каркас лестничной логики по ступеням
• Использовать один путь владения выходом для DO_Mixer_Run
• Добавить комментарии к ступеням
• Указать любые допущения

1. По команде старта начать цикл смешивания, только если крышка закрыта и E-stop в порядке
2. Запустить двигатель смесителя на 10 секунд
3. Остановить двигатель, когда таймер завершит работу
4. Немедленно прервать, если команда стоп, крышка открыта или E-stop не в порядке

Что проверить после генерации

После того как Yaga сгенерирует лестничную логику, проверьте:

• один четкий путь владения для `DO_Mixer_Run`,
• разрешение таймера, привязанное к состоянию активного цикла,
• немедленное отключение при открытии крышки или потере E-stop,
• отсутствие скрытого автоперезапуска,
• комментарии, соответствующие фактическому поведению ступени,
• явные допущения.

Затем запустите это в симуляции и принудительно установите `DI_Lid_Closed` в значение false во время работы таймера. Если команда на двигатель сохраняется, промпт или логика неверны.

Инженеры должны документировать работу с ПЛК при поддержке ИИ как инженерное доказательство, а не как галерею скриншотов интерфейса. Достоверная запись показывает, что система должна была делать, как она тестировалась, как она давала сбой и как это было исправлено.

Используйте эту структуру:

Запишите точно введенную неисправность: потерю датчика, перегрузку, потерю разрешения, тайм-аут, неверное аналоговое значение и так далее.

1. Описание системы Определите оборудование, цель процесса, режим работы и безопасное состояние.
2. Операционное определение «правильного» Укажите наблюдаемые критерии успеха, включая условия остановки и поведение при нештатном состоянии.
3. Лестничная логика и состояние симулируемого оборудования Покажите сгенерированную или отредактированную лестничную логику вместе с соответствующим состоянием симулируемой машины или поведением переменных.
4. Внедренный случай неисправности
5. Внесенные исправления Задокументируйте изменение логики или уточнение промпта, использованное для исправления поведения.
6. Извлеченные уроки Укажите, что сбой выявил в отношении исходной концепции управления, допущений или дизайна последовательности.

Это создает компактный массив доказательств, который полезен рецензентам, инструкторам или менеджерам по найму.

Использование ИИ при программировании ПЛК полезно для создания каркаса, черновиков и ускорения структуры логики первого прохода. Этого недостаточно для валидации безопасности, подписания актов ввода в эксплуатацию или принятия решений о внедрении на конкретном объекте.

Эта граница важна как для этики, так и для инженерии. OLLA Lab здесь описана как веб-интерактивный симулятор лестничной логики и цифровой двойник с поддержкой через Yaga, 3D/WebXR/VR симуляциями, сценарными упражнениями, аналоговыми и ПИД-инструментами и рабочими процессами инструкторов. Эти функции делают ее полезной как среду для репетиции и валидации. Они не превращают сгенерированную логику в одобренную логику установки по ассоциации.

Несколько ограничений должны оставаться явными:

• Сгенерированная ИИ лестничная логика может быть синтаксически правдоподобной и функционально небезопасной.
• Симуляция может выявить многие дефекты логики, но она не идентична вводу в эксплуатацию на объекте.
• Валидация цифрового двойника зависит от точности модели и охвата сценариев.
• Обязательства по функциональной безопасности все равно требуют формальных методов, компетентной проверки и дисциплины жизненного цикла, основанной на стандартах.

Это согласуется с более широкой литературой по безопасности. IEC 61508 и соответствующие руководства рассматривают систематические сбои, ошибки спецификации и дисциплину верификации как центральные проблемы. Модель, которая быстро создает код, не снимает эти обязанности.

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

Это дает три практических преимущества:

• лучший каркас первого прохода,
• более быстрая отладка в симуляции,
• более понятная проверка людьми.

Это также прививает правильную привычку. Профессиональный переход заключается не только в переходе от незнания лестничной логики к ее знанию. Он заключается в переходе от написания ступеней к защите поведения.

- Обзор стандарта IEC 61131-3 (PLCopen) - Рамочная программа NIST по управлению рисками ИИ (AI RMF 1.0) - Обзор руководящих принципов доступности веб-контента (WCAG) 2 W3C - Портал таксономии и публикаций IEEE - Страница стандарта ISO/IEC 23894 по управлению рисками ИИ