Как построить логические вентили XOR и NAND в ПЛК с помощью OLLA Lab

Для перевода булевой алгебры в релейную логику стандарта МЭК 61131-3 инженеры сопоставляют абстрактные логические состояния с поведением контактов и выходных катушек, основанным на цикле сканирования. В OLLA Lab вентили XOR и NAND — это не просто графические символы; они проходят валидацию на основе моделируемых входов/выходов, состояний неисправности и логики отклика оборудования перед любым реальным внедрением.

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

Внутренний бенчмарк Ampergon Vallis наглядно демонстрирует это: 68% пользователей не справились с первой попыткой создания аварийной сигнализации рассогласования при реализации поведения XOR в OLLA Lab [Методология: n=500 последовательностей логики для начинающих, задача определена как создание и тестирование двухвходовой сигнализации рассогласования в среде моделирования, базовый компаратор = успех/провал с первой попытки в сравнении с ожидаемой таблицей истинности и моделируемым поведением, временной интервал = январь-февраль 2026 г.]. Это подтверждает лишь одно ограниченное утверждение: перевод булевых намерений в корректную структуру релейной логики сложнее, чем простое распознавание таблицы истинности. Это не подтверждает никаких более широких выводов о компетентности инженеров в отрасли.

Булева алгебра описывает логические взаимосвязи. Релейная диаграмма (LD) по стандарту МЭК 61131-3 описывает, как эти взаимосвязи реализуются в системе управления, основанной на цикле сканирования.

Практическое различие заключается в следующем:

- Логика ПЛК выполняется циклически: чтение входов -> выполнение логики -> запись выходов.

• Булева алгебра рассматривает переменные, такие как A и B, как абстрактные логические состояния.
• Релейная логика сопоставляет эти состояния с тегами, битами памяти и физическими или моделируемыми входами/выходами.
• Булевы выражения читаются как статические отношения.

Поведение цикла сканирования имеет значение, поскольку цепь (rung) — это не просто символическое уравнение. Она вычисляется последовательно с использованием текущего образа процесса в контроллере.

### Базовая матрица трансляции: от булевой алгебры к релейной логике

Стандартные первичные соответствия просты:

• AND (И) -> последовательное соединение контактов
• OR (ИЛИ) -> параллельное соединение контактов
• NOT (НЕ) -> представление нормально замкнутого (НЗ) контакта
• TRUE (ИСТИНА) -> запитанная катушка или внутренний бит
• FALSE (ЛОЖЬ) -> обесточенная катушка или сброшенный бит

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

Почему физический уровень меняет смысл

Булева переменная — это не провод. В ПЛК тег может представлять:

• полевой вход 24 В пост. тока,
• внутренний бит памяти,
• производный статус,
• условие разрешения (permissive),
• условие срабатывания защиты (trip),
• или состояние моделируемого оборудования.

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

Почему важен стандарт МЭК 61131-3

МЭК 61131-3 стандартизирует языки программирования, включая релейные диаграммы (LD), функциональные блочные диаграммы (FBD) и структурированный текст (ST) для программируемых контроллеров (IEC, 2013). Он не стирает различия в реализации между поставщиками, но предоставляет общую модель выполнения и языковую структуру.

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

Вентиль NAND (И-НЕ) выдает ложь только тогда, когда оба входа истинны. В промышленном управлении это делает его полезным для шаблонов разрешений и запретов, где выход остается доступным, пока не будет одновременно выполнена определенная комбинация условий.

Булева форма:

• C = NOT (A AND B)

Эквивалентная интерпретация в релейной логике:

• Выход C включен, когда A ложно, или B ложно, или оба ложны.
• Выход C выключается только тогда, когда A и B оба истинны.

Почему NAND используется в промышленной логике

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

Типичные примеры включают:

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

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

Реализация вентиля NAND в релейной логике

Распространенная двухветвевая форма:

[Язык: Релейная диаграмма] // Вентиль NAND: Выход ВКЛ, если только оба входа A и B не ВКЛ.

|----[/]----------------------------------------( )----| | Вход A Выход C | | | |----[/]------------------------------------------------| | Вход B |

В этой цепи используются параллельные нормально замкнутые (НЗ) контакты:

• Если Вход A = 0, верхняя ветвь истинна.
• Если Вход B = 0, нижняя ветвь истинна.
• Если любая из ветвей истинна, Выход C запитывается.
• Только когда A = 1 и B = 1, оба НЗ-контакта становятся ложными, обесточивая выход.

Таблица истинности для NAND в терминах релейной логики

| Вход A | Вход B | Выход C | |--------|--------|----------| | 0 | 0 | 1 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

Как построить вентиль NAND в OLLA Lab

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

Важный шаг — не просто нарисовать цепь, а доказать поведение:

• оба входа ложны -> выход включен,
• один вход истинен -> выход включен,
• оба входа истинны -> выход выключен.

1. Создайте теги для Input_A, Input_B и Output_C.
2. Вставьте два нормально замкнутых контакта на отдельных параллельных ветвях.
3. Назначьте одну ветвь на Input_A, а другую на Input_B.
4. Разместите Output_C как управляемую катушку.
5. Запустите симуляцию.
6. Переключайте входы на панели переменных и проверьте таблицу истинности.

Реалистичный пример разрешения

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

• A = Выбран удаленный режим
• B = Активна последовательность автозапуска

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

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

Булева форма:

• C = (A AND NOT B) OR (NOT A AND B)

В терминах релейной логики XOR обычно строится как две параллельные ветви с перекрестным соединением нормально разомкнутых (НР) и нормально замкнутых (НЗ) контактов.

Почему XOR важен в диагностике машин и процессов

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

Классический пример — клапан с:

• Концевым выключателем открытия
• Концевым выключателем закрытия

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

Реализация вентиля XOR в релейной логике

[Язык: Релейная диаграмма] // Вентиль XOR: Выход ВКЛ, если A или B ВКЛ, но не оба сразу.

|----[ ]--------[/]----------------------------( )----| | Вход A Вход B Авария C | | | |----[/]--------[ ]------------------------------------| | Вход A Вход B |

Эта цепь работает следующим образом:

• Верхняя ветвь истинна, когда A = 1 и B = 0
• Нижняя ветвь истинна, когда A = 0 и B = 1
• Если любая ветвь истинна, Авария C запитывается
• Если оба входа одинаковы, авария остается выключенной

Таблица истинности для XOR в терминах релейной логики

| Вход A | Вход B | Авария C | |--------|--------|---------| | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

Как XOR поддерживает сигнализацию рассогласования

Для сигнализации рассогласования XOR полезен, когда условие аварии определяется как «два сигнала состояния не совпадают».

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

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

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

Как построить вентиль XOR в OLLA Lab

Используйте OLLA Lab для создания и тестирования цепи рассогласования прямо в браузере:

Тестовая последовательность должна подтвердить:

• 00 -> авария выкл
• 01 -> авария вкл
• 10 -> авария вкл
• 11 -> авария выкл

Если цепь делает что-то другое, проблема обычно в одном из трех:

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

1. Создайте теги для Input_A, Input_B и Alarm_C.
2. Добавьте две параллельные ветви.
3. На первой ветви разместите НР Input_A последовательно с НЗ Input_B.
4. На второй ветви разместите НЗ Input_A последовательно с НР Input_B.
5. Управляйте Alarm_C выходом ветви.
6. Запустите симуляцию и переключайте оба входа через все четыре состояния.

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

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

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

Большинство ПЛК следуют этой общей схеме выполнения:

1. Чтение входов
2. Выполнение логики программы
3. Обновление выходов
4. Выполнение коммуникаций, диагностики, служебных задач

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

Почему это важно для логики рассогласования

Авария рассогласования XOR может вести себя по-разному в зависимости от:

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

Например:

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

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

Почему это важно для разрешений

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

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

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

Что здесь означает «Готовность к симуляции»

В этой статье Готовность к симуляции означает, что инженер может:

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

Как протестировать случай отказа NAND в OLLA Lab

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

• Установите Input_A = 0, Input_B = 0 -> подтвердите Output_C = 1
• Установите Input_A = 1, Input_B = 0 -> подтвердите Output_C = 1
• Установите Input_A = 0, Input_B = 1 -> подтвердите Output_C = 1
• Установите Input_A = 1, Input_B = 1 -> подтвердите Output_C = 0

Затем введите сценарий неисправности:

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

Как протестировать отказ рассогласования XOR в OLLA Lab

Для модели аварии рассогласования:

- Затем смоделируйте случай неисправности, такой как:

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

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

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

Симуляция сокращает разрыв между построением цепи и доказательством поведения. Исследования цифровых двойников, обучения на основе симуляции и киберфизической валидации указывают на ценность виртуального тестирования для снижения рисков, улучшения понимания поведения системы и поддержки более раннего обнаружения неисправностей в рабочих процессах автоматизации (Tao et al., 2019; Fuller et al., 2020; Villalonga et al., 2021).

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

Хороший рабочий процесс определяет правильность до начала тестирования. Если «правильность» остается расплывчатой, симуляция превращается в театр.

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

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

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

Определите аномальное условие. Пример: «Концевой выключатель закрытия залип в высоком состоянии во время перехода по команде открытия».

Покажите, что изменилось. Пример: «Добавлен таймер перехода и квалификатор состояния команды для подавления ложной тревоги во время нормального движения».

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

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

Самая распространенная ошибка — полагать, что таблица истинности и есть проект. Это не так. Таблица истинности — это лишь начальное ограничение.

Частые ошибки реализации

• Перепутывание НР и НЗ контактов
• Смешение смысла сигнала с состоянием сигнала
• Игнорирование эффектов цикла сканирования
• Тестирование только ожидаемого случая
• Рассмотрение логики разрешения как эквивалентной логике безопасности
• Неспособность определить модель состояния процесса

Практическая коррекция

При построении любой цепи на основе вентилей определите три вещи перед симуляцией:

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

Эта дисциплина устраняет удивительное количество путаницы. Многие «логические ошибки» на самом деле являются ошибками спецификации.

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

Это включает:

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

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

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

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

Булева алгебра дает вам логическую форму. Релейная логика МЭК 61131-3 дает вам исполняемую структуру. Инженерная задача заключается в переводе между ними, особенно когда в картину входят тайминги сканирования, поведение устройств и состояния неисправностей.

NAND и XOR — полезные примеры, потому что они четко обнажают этот перевод:

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

В обоих случаях цепь — это только начало. Настоящая работа — это доказательство поведения в нормальных и аномальных условиях. Именно здесь среда симуляции окупает себя.

Рекомендуемая литература

- См. «Переход к системному мышлению: выход за рамки рисования цепей».

• Для более широкого контекста стандартов посетите наш Центр мастерства релейной логики (Ladder Logic Mastery Hub).
• См. «Почему нормально замкнутые контакты — это самые важные цепи, которые вы напишете».
• Готовы протестировать эту логику рассогласования? Откройте пресет управления клапаном в OLLA Lab.

- IEC 61131-3: Программируемые контроллеры — Часть 3 - Семейство стандартов функциональной безопасности IEC 61508 - Ресурсы exida по функциональной безопасности и валидации - Рекомендация NAMUR NE 107 по сигнализации статуса - Цифровой двойник в промышленности: современное состояние (DOI)