Почему LLM не справляются с релейной логикой? Преимущество графического подхода в OLLA Lab

Большие языковые модели (LLM) испытывают трудности с релейной логикой (Ladder Logic), поскольку они прогнозируют одномерный текст, в то время как релейные диаграммы (LD) и SFC зависят от двухмерных пространственных связей, параллельного выполнения и порядка циклов сканирования. OLLA Lab предоставляет среду визуального моделирования, где инженеры могут проверять потоки питания, поведение входов/выходов и ошибки синхронизации до того, как логика попадет в реальный технологический процесс.

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

В ходе недавнего внутреннего тестирования 50 схем управления двигателями, сгенерированных ИИ и импортированных в движок моделирования OLLA Lab, 68% предложенных ИИ последовательностей дали сбой уже на первом виртуальном цикле сканирования. Основными причинами стали ошибки в порядке расположения ступеней (rung-order) и зависимостях состояний, а не синтаксические ошибки. Методология: объем выборки = 50 задач по управлению двигателем; определение задачи = импорт и моделирование сгенерированных ИИ шаблонов пуска/остановки, самоподхвата, условий разрешения и сброса неисправностей; эталон для сравнения = вручную проверенные эталонные реализации, принятые инженерным отделом Ampergon Vallis; временной интервал = I квартал 2026 года. Этот показатель подтверждает узкий тезис: сгенерированная ИИ релейная логика часто ломается на этапе выполнения, даже если она выглядит структурно правдоподобно. Это не означает, что вся логика ПЛК, созданная ИИ, непригодна к использованию.

В этом и заключается реальная проблема: правдоподобность текста против работоспособного поведения системы управления. ПЛК не оценивают эссе.

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

Стандарт IEC 61131-3 определяет релейные диаграммы (LD) и последовательные функциональные схемы (SFC) как графические языки, используемые для выражения связей управления, которые легче осмыслить визуально, чем в виде простого текста (IEC, 2013). В LD структура ветвей, поток питания, порядок ступеней и параллельные условия являются частью смысла. В SFC расхождение, схождение, активные шаги и владение переходом также являются частью смысла. Когда эта структура «сплющивается» в XML, JSON или текст промпта, часть контекста выполнения легко теряется или интерпретируется неверно.

Разрыв между 1D и 2D выполнением

В первую очередь сериализуют замысел в линейном порядке. Даже при выражении ветвления или параллелизма представление остается последовательным и явным.

• Текстовые языки, такие как Python или C

Кодирует логику как электрическую сеть с потоком питания слева направо и оценкой сверху вниз. Параллельные ветви — это не декорация; они определяют отношения выполнения.

• Релейная диаграмма (LD)

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

• Последовательная функциональная схема (SFC)

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

• LLM

Исследования рассуждений LLM неоднократно показывали, что предсказание токенов не гарантирует сохранение пространственной или топологической структуры, особенно когда задача требует согласованного отображения в нелинейных представлениях (Bubeck et al., 2023; Bang et al., 2023). Детали варьируются в зависимости от бенчмарка, но тенденция стабильна: модели последовательностей лучше справляются с правдоподобным продолжением, чем с детерминированным пространственным учетом.

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

Что на самом деле означает «овладение визуальной логикой»?

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

Операционно это означает, что инженер может:

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

Именно это Ampergon Vallis подразумевает под Simulation-Ready (готовностью к моделированию): инженер, который может доказать, наблюдать, диагностировать и укрепить логику управления против реалистичного поведения процесса до того, как она попадет в реальную систему. Это не беглость в синтаксисе. Это не «театр резюме». Это доказательства.

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

Стандартная модель сканирования проста:

1. Чтение входов
2. Выполнение логики
3. Обновление выходов
4. Повтор

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

Ошибка «выглядит правильно»

Самая распространенная ошибка ИИ — это не неверный синтаксис. Это логика, которая выглядит корректной, но имеет неверное поведение при выполнении.

Примеры включают:

Бит разрешения проверяется на ступени 2, но логика, которая его устанавливает, выполняется только на ступени 5.

• Инвертированный порядок ступеней

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

• Преждевременная зависимость от выхода

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

• Нарушенная логика самоподхвата

Логика сброса неисправности очищает ошибку до того, как будут повторно проверены условия подтверждения, создавая последовательность, которая выглядит аккуратно в тексте, но потенциально небезопасна в эксплуатации.

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

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

• Недопустимые или некомпилируемые структуры ветвей

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

Типичные пространственные ошибки ИИ, обнаруженные в OLLA Lab

В рабочем процессе моделирования OLLA Lab эти режимы отказа обычно видны уже при первом прогоне:

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

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

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

SFC часто сложнее для LLM, чем базовая релейная логика, потому что модель должна сохранять:

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

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

Почему преобразование в текст ослабляет рассуждения об SFC

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

Что ослабляется:

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

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

На практике SFC наказывает за поверхностную сериализацию.

Графическое представление важно, потому что корректность управления — это не только логическая корректность. Это также наблюдаемая корректность последовательности в условиях реалистичного поведения установки.

В промышленной автоматизации вопрос редко звучит просто как «компилируется ли ступень?». Реальный вопрос ближе к следующему:

• Запускается ли насос только тогда, когда условия разрешения истинны?
• Приходит ли обратная связь подтверждения в ожидаемое время?
• Правильно ли фиксируется сигнал тревоги?
• Сбрасывается ли авария только при соблюдении условий?
• Безопасно ли восстанавливается последовательность после нештатного состояния?
• Соответствует ли поведение моделируемого оборудования предполагаемой философии управления?

Вот почему стандарты и практика безопасности подчеркивают валидацию, верификацию и дисциплину жизненного цикла, а не доверие к сгенерированному коду «на слово». IEC 61508, например, четко говорит о системной целостности, качестве спецификаций, строгости верификации и опасности скрытых дефектов проектирования в программируемых системах (IEC, 2010). В нем нет специального исключения для кода, который выглядел убедительно в окне чата.

Моделирование и валидация на основе цифровых двойников становятся все более актуальными, поскольку они позволяют инженерам тестировать поведение до выхода на объект. Литература обширна и неоднородна, но центральный результат последователен: обучение на основе моделирования и виртуальная пусконаладка могут улучшить обнаружение неисправностей, понимание последовательностей и готовность операторов или инженеров, когда моделирование привязано к реалистичному поведению процесса, а не только к общей визуализации (Tao et al., 2019; Negri et al., 2017; Uhlemann et al., 2017).

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

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

Что делает OLLA Lab в этом рабочем процессе

В рамках продукта OLLA Lab предоставляет:

• веб-редактор релейной логики для создания и пересмотра ступеней,
• режим моделирования для безопасного запуска и остановки логики,
• панель переменных для мониторинга входов, выходов, тегов, аналоговых значений и состояний, связанных с ПИД-регуляторами,
• 3D/WebXR/VR виды оборудования (где доступно),
• сценарии лабораторных работ, которые связывают релейную логику с реалистичным поведением машины или процесса.

При правильном использовании это поддерживает дисциплинированный рабочий процесс:

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

Именно здесь OLLA Lab становится операционно полезной. Она превращает «модель дала мне код» в «инженер наблюдал последовательность, нашел ошибку и исправил ее».

Какие функции OLLA Lab наиболее важны для проверки ИИ?

Для этой конкретной проблемы наиболее полезны функции, которые раскрывают состояние выполнения, а не просто декорируют его:

Позволяет инженеру напрямую проверять структуру ветвей и порядок ступеней.

• Визуальный редактор релейной логики

Позволяет инженеру безопасно запускать логику и наблюдать причинно-следственные связи без оборудования.

• Режим моделирования

Делает состояние тегов, аналоговые значения и поведение выходов видимыми во время тестирования.

• Панель переменных и видимость входов/выходов

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

• Сценарные упражнения

Помогает пользователям перейти от построения первой ступени к более продвинутому поведению (таймеры, счетчики, сравнения, ПИД).

• Управляемый рабочий процесс сборки

Может помочь с онбордингом и корректирующими предложениями, но окончательным авторитетом остается наблюдаемое поведение моделирования и инженерная проверка.

• Руководство лаборатории GeniAI

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

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

Рабочая последовательность валидации:

1. Определите замысел управления перед просмотром кода

Запишите:

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

Если философия управления расплывчата, проверка кода тоже будет расплывчатой. Машина обычно это замечает.

2. Проверьте порядок выполнения, а не только синтаксис

Проверьте:

• порядок ступеней,
• законность ветвей,
• зависимости состояний,
• поведение защелок (latch/unlatch),
• последовательность сброса,
• порядок аналоговых порогов,
• не ссылается ли какой-либо выход на логику, которая еще не решена.

3. Смоделируйте номинальные и нештатные случаи

Как минимум, протестируйте:

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

4. Сравните состояние контроллера с состоянием оборудования

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

5. Пересматривайте и повторяйте тест до тех пор, пока последовательность не станет стабильной

Один успешный прогон — это не валидация. Это первый проход.

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

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

1) Описание системы

Укажите, что это за система и что она должна делать.

Пример:

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

2) Операционное определение «правильности»

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

Пример:

• Конвейер запускается только при закрытом ограждении и исправном состоянии защиты от перегрузки.
• Аварийное отключение по затору останавливает движение в рамках моделируемой последовательности.
• Сброс заблокирован до тех пор, пока датчик затора не очистится.
• Повторный пуск требует новой команды пуска.

3) Релейная логика и состояние моделируемого оборудования

Покажите релейную логику и поведение моделируемой машины вместе.

Пример:

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

4) Случай с внесенной неисправностью

Намеренно введите одно нештатное условие.

Пример:

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

5) Внесенные изменения

Запишите изменение логики.

Пример:

• Добавлен таймер подтверждения и защелка аварии.
• Перемещено условие разрешения сброса ниже условия очистки неисправности.
• Изменен порядок оценки ступеней для устранения зависимости от устаревшего состояния.

6) Извлеченные уроки

Укажите, чему научил сбой.

Пример:

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

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

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

Разумные варианты использования:

• генерация черновиков паттернов ступеней,
• объяснение таймеров, счетчиков, компараторов и ПИД-блоков,
• перевод комментариев или описаний тегов,
• предложение тестовых случаев,
• обобщение текста философии управления,
• помощь обучающимся в понимании того, почему последовательность дала сбой.

Менее разумные варианты использования:

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

Практическое различие простое: генерация черновика против детерминированного вето. ИИ может помочь написать черновик. Моделирование и инженерная проверка имеют право вето.

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

Этот вывод не означает, что ИИ не имеет отношения к автоматизации. Это означает, что бремя валидации твердо остается на инженере.

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

Синтаксис дешев. Детерминизм — это дорогая часть.

- Эта пространственная слепота является основной причиной того, что мы называем «синдромом двойной катушки»: почему ваш ИИ-помощник не понимает циклы сканирования. - Для более глубокого изучения перевода диалектов см. наш разбор «Агенты, учитывающие вендора: преодоление разрыва между LLM и реальными ПЛК».

• Изучите наше полное руководство по будущему автоматизации и инженерии, устойчивой к ИИ.
• Готовы проверить свой сгенерированный ИИ код? Откройте пресет «Пускатель двигателя» в OLLA Lab и протестируйте поток питания в режиме моделирования.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety standards family - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industry 5.0 policy background - Digital twin overview (NIST)

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

Статья прошла внутреннюю проверку инженерным отделом Ampergon Vallis на соответствие стандартам IEC 61131-3 и принципам функциональной безопасности. Все данные о производительности ИИ основаны на результатах тестирования, проведенного в I квартале 2026 года.