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

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

ИИ не становится безопасным только потому, что он звучит уверенно. В промышленном управлении уверенность не является переменной управления.

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

В недавней внутренней серии из 500 симулированных аномалий уставок, сгенерированных ИИ и пропущенных через рабочие процессы валидации цифровых двойников OLLA Lab, ограничение скорости изменения на стороне ПЛК в сочетании с явными разрешающими сигналами состояния заблокировало 100% катастрофических команд, выходящих за пределы допустимых значений, до того, как они воздействовали на виртуальные модели клапанов и двигателей. Методология: n=500 случаев инъекции аномалий в задачах с ограниченной скоростью, давлением и положением клапана; базовый компаратор = прямая передача команды, запрошенной ИИ, на тег симулируемого исполнительного механизма; временной интервал = внутренние лабораторные запуски Ampergon Vallis, проведенные в 1 квартале 2026 года. Это подтверждает ценность детерминированной верификации в симуляции. Это не является сертификацией по IEC 61508, доказательством SIL или заявлением относительно всех архитектур предприятий.

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

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

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

Стандарты IEC 61508 и ISO 13849 построены вокруг предсказуемого поведения, определенной обработки отказов и известных безопасных состояний. Функции управления, связанные с безопасностью, должны приводить к отказам способами, которые можно проанализировать, ограничить и валидировать. Современные системы типа LLM не соответствуют этой планке, потому что их режимы отказа не могут быть исчерпывающе охарактеризованы так, как того требует детерминированная логика безопасности. В этом и заключается реальная проблема: не в том, что ИИ — это что-то новое, а в том, что ИИ недостаточно систематически ограничен, чтобы владеть финальным путем исполнения команд.

Цикл сканирования против движка логического вывода

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

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

Это создает два класса рисков:

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

ПЛК может терпеть задержки или отклоненные запросы. Насосная станция не может терпеть фантазии.

Что на самом деле требуют стандарты?

Стандарты требуют предсказуемого поведения безопасности, а не модного программного обеспечения.

На высоком уровне:

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

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

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

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

На практике детерминированное вето часто включает:

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

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

Операционные определения, которые имеют значение

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

- Детерминированное вето: логика ПЛК, которая оценивает внешний или сгенерированный ИИ запрос при каждом сканировании и блокирует небезопасное исполнение через явные границы, разрешающие сигналы и правила отказов. - Многоуровневая защита: архитектурное разделение между функциями ИИ/ИТ, которые предлагают или оптимизируют, и функциями ПЛК/ОТ, которые проверяют, исполняют и обеспечивают границы безопасности. - Готовность к симуляции (Simulation-Ready): способность отслеживать причинно-следственные связи входов/выходов, наблюдать ненормальное поведение, вводить сценарии отказов, диагностировать реакцию управления и пересматривать логику в виртуальной среде до взаимодействия с физическим оборудованием.

«Готовность к симуляции» — это не сокращение для «умеет писать на языке лестничных диаграмм». Это означает, что инженер может доказать поведение под нагрузкой. Синтаксис дешев; возможность развертывания — нет.

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

Разделение должно быть явным:

### Уровень 1: Агент ИИ для восприятия или оптимизации

Этот уровень может:

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

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

### Уровень 2: Детерминированное вето в ПЛК

Этот уровень оценивает запрос ИИ на соответствие фиксированным инженерным правилам, таким как:

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

Именно здесь команда становится либо приемлемой, либо модифицированной, либо отклоненной.

### Уровень 3: Аппаратный или сертифицированный путь исполнения безопасности

Этот уровень включает, по мере необходимости:

• цепи аварийного останова (E-stop),
• реле безопасности,
• задачи ПЛК безопасности,
• контакторы,
• цепи STO (Safe Torque Off),
• блокировки защитных ограждений,
• независимые функции отключения.

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

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

Ключевой принцип проектирования прост: запросы ИИ — это предложения, а не выходы.

Реализация ограничения уставки

Ограничение границ (clamp) предотвращает достижение исполнительным механизмом невозможных или небезопасных значений.

Используйте структуру, подобную этой:

Пример перевода на структурированный текст / лестничную логику:

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

Это минимальный шаблон, а не готовая архитектура.

Реализация, ориентированная на производство, обычно добавляет:

- проверку режима: принимать запросы ИИ только в автоматическом режиме - разрешающий сигнал состояния: принимать запросы только тогда, когда машина находится в допустимом состоянии последовательности - ограничение ROC (скорости изменения): ограничить изменение за сканирование или за секунду - бит качества: отклонять устаревшие, недействительные или недоверенные входящие данные - обработку тайм-аутов: возврат к резервному значению, если поток запросов прерывается - фиксацию аварийных сигналов и видимость для оператора: сделать отклонение видимым и доступным для анализа

Более полный путь управления часто выглядит так:

1. Получить `AI_Requested_Speed`
2. Проверить качество и свежесть источника
3. Подтвердить `System_Auto = TRUE`
4. Подтвердить, что все разрешающие сигналы истинны
5. Ограничить инженерными мин/макс значениями
6. Применить лимит ROC
7. Записать в `Actual_Drive_Speed_Command`
8. Отключить или заблокировать, если цепь безопасности разомкнута

Что должна обеспечивать лестничная логика перед пропуском команды ИИ?

ПЛК должен обеспечивать то же самое, о чем спросил бы осторожный инженер по пусконаладке перед подачей питания на оборудование:

• Находится ли машина в правильном режиме?
• Находится ли последовательность на правильном шаге?
• Выполнены ли все разрешающие условия?
• Исправны ли обратные связи?
• Находится ли запрошенное значение в физических пределах?
• Является ли запрошенное изменение правдоподобным для этого процесса?
• Есть ли какие-либо активные условия отключения или безопасности?

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

Главная цепь аварийного останова

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

На практике:

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

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

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

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

Как минимум, протестируйте следующие случаи:

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

Для каждого случая проверьте:

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

Вето, которое правильно ограничивает, но оставляет последовательность в некогерентном состоянии, — это лишь половина решения.

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

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

Внутри OLLA Lab инженеры могут:

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

Для варианта использования, описанного в этой статье, рабочий процесс прост:

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

Именно здесь OLLA Lab становится операционно полезной. Вы не можете ответственно протестировать галлюцинацию с командой открытия клапана на 200% на реальной технологической установке, просто чтобы посмотреть, что произойдет. Любопытство ценно; погнутое оборудование стоит дорого.

Как «Готовность к симуляции» выглядит на практике

Инженер готов к симуляции (Simulation-Ready), когда он может сделать все следующее в виртуальной среде:

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

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

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

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

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

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

Запишите, что изменилось в логике: добавлено ограничение, ужесточен разрешающий сигнал, введен тайм-аут, зафиксирован аварийный сигнал, скорректирован лимит ROC.

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

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

Самая распространенная ошибка — позволить ИИ обойти уровень верификации.

Другие повторяющиеся ошибки включают:

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

Сгенерированная ступень — это не доказанная ступень. Промышленное управление по-прежнему определяется тем, что машина делает на самом деле.

Правильный паттерн — это не «ИИ управляет заводом». Правильный паттерн — «ИИ может предлагать, но ПЛК решает, а уровень безопасности все еще может сказать "нет"».

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

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

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

Данная статья прошла внутреннюю проверку на соответствие принципам функциональной безопасности (IEC 61508) и методологии тестирования цифровых двойников Ampergon Vallis Lab.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 overview (functional safety) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)