Как проверить логику ПЛК с помощью SITL и цифровых двойников OLLA Lab

Тестирование Software-in-the-Loop (SITL) в промышленной автоматизации — это выполнение управляющей логики ПЛК на программной модели поведения оборудования, а не на физическом контроллере. В OLLA Lab логику на языке релейных схем (LD) можно протестировать на 3D-цифровых двойниках, чтобы проверить тайминги последовательностей, блокировки, поведение в нештатных ситуациях и восстановление после сбоев до начала пусконаладочных работ.

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

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

Согласно внутреннему анализу Ampergon Vallis, охватывающему 1200 сценариев моделирования в OLLA Lab, пользователи, проверявшие логику на 3D-цифровом двойнике, выявили 84% смоделированных механических состояний гонки (race conditions) до первого физического запуска. Методология: объем выборки = 1200 запусков сценариев в предустановленных и пользовательских лабораториях; определение задачи = обнаружение смоделированных состояний гонки, таких как перекрывающиеся срабатывания и конфликты индексации; базовый компаратор = проверка логики и состояние «компиляция успешна» без выполнения на цифровом двойнике; временной интервал = январь 2025 г. – февраль 2026 г. Это подтверждает, что моделирование может выявить классы ошибок, которые пропускают обычные проверки синтаксиса. Это не доказывает надежность в полевых условиях, компетентность оператора или соответствие требованиям безопасности.

SITL, HIL и физическая пусконаладка отвечают на разные вопросы проверки. Относиться к ним как к взаимозаменяемым — верный способ упустить риски.

Согласно концепции виртуальной пусконаладки, описанной в VDI 3693, Software-in-the-Loop (SITL) означает, что и логика контроллера, и поведение установки представлены в программном обеспечении, без необходимости наличия физического ПЛК, полевой проводки или аппаратного обеспечения машины. Цель состоит в том, чтобы проверить поведение управления в ответ на смоделированный отклик процесса в среде с контролируемым риском.

Hardware-in-the-Loop (HIL) на один шаг ближе к реальности. Установка остается смоделированной, но вводится реальное аппаратное обеспечение контроллера. Это позволяет проверить аппаратные тайминги, обработку ввода-вывода и некоторые специфические для платформы особенности поведения, которые SITL не может полностью воспроизвести.

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

### Сравнение: SITL vs HIL vs физическая пусконаладка

| Режим проверки | Что реально | Что смоделировано | Основная цель | Уровень риска | |---|---|---|---|---| | SITL | Среда выполнения логики управления | Поведение установки/оборудования | Проверка логики последовательностей, блокировок, допущений по времени, переходов состояний, обработки ошибок | Низкий | | HIL | Физическое оборудование ПЛК/контроллера | Поведение установки/оборудования | Проверка выполнения, специфичного для контроллера, поведения I/O, аппаратных таймингов, допущений интеграции | Средний | | Физическая пусконаладка | ПЛК, проводка, датчики, приводы, машина/процесс | Почти ничего или ничего | Проверка развернутой системы в реальных условиях эксплуатации | Высокий |

В чем сильные стороны SITL

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

Что SITL не заменяет

• Приемо-сдаточные испытания (SAT)
• Проверку контуров и верификацию проводки
• Проверку функциональной безопасности
• Определение уровня полноты безопасности (SIL) или демонстрацию соответствия
• Обучение операторов на конкретном установленном активе (если объем модели не поддерживает это)

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

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

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

Три физические реальности, которые игнорируют компиляторы

1. Механическая инерция Команда «стоп» не приводит к мгновенной остановке. Двигатели вращаются по инерции, конвейеры перебегают, а подвешенные грузы продолжают движение. Логика может быть верной на уровне скана, но неверной на уровне машины.
2. Задержка датчиков Реальные датчики имеют время отклика, допуски на монтаж, дребезг и фильтрацию. Фотодатчик или концевой выключатель, который меняет состояние на несколько миллисекунд позже ожидаемого, может нарушить элегантную последовательность.
3. Трение покоя приводов и задержка процесса Пневматическим цилиндрам нужно время для нагнетания давления. Клапаны могут заедать перед движением. Насосы не создают стабильный поток в тот же миг, когда включается бит двигателя. Релейной схеме все равно; процессу — нет.

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

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

Рассмотрим сортировочный конвейер с толкающим цилиндром:

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

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

В этой статье цифровой двойник — это не маркетинговый синоним 3D-графики. Это программная модель, которая обменивается состояниями с логикой управления в детерминированном цикле проверки.

Операционно, цифровой двойник для проверки ПЛК — это:

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

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

Полезный цифровой двойник для задач управления должен делать четыре вещи

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

• Потреблять выходы контроллера

Пример: ускорение, замедление, время выдержки, время перемещения, задержка давления, изменение уровня или задержка процесса.

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

Пример: датчики приближения, фотодатчики, концевые выключатели, аналоговые значения (PV), состояния аварий, сигналы подтверждения.

• Возвращать смоделированные входы в логику

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

• Сохранять детерминированные условия тестирования

В этом разница между видео и средой проверки. Одно — иллюстративно. Другое может наложить вето на плохую логику управления.

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

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

Практический рабочий процесс привязки тегов в OLLA Lab

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

• Определите командные теги в логике
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Определите теги обратной связи и датчиков
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Привяжите командные теги к поведению цифрового двойника
• `Conveyor_Run_CMD` управляет состоянием движения конвейера
• `Cylinder_Extend_CMD` управляет последовательностью выдвижения привода

• Привяжите отклики смоделированного оборудования обратно к тегам
• Движение конвейера обновляет `Conveyor_At_Speed`
• Виртуальный концевой выключатель обновляет `Cylinder_Extended_LS`
• Виртуальный луч или обнаружение объекта обновляет `Photoeye_PE1`

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

Что это дает инженеру

• Видимую цепочку «причина-следствие» между логикой ступеней и откликом машины
• Место для проверки того, достаточны ли блокировки
• Способ проверки несоответствий таймингов между командой и подтверждением
• Безопасную среду для внесения ошибок, которые были бы дорогими или опасными на реальном оборудовании

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

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

Обязательные тестовые случаи SITL

Активируйте аварийную остановку во время движения, когда механизм несет или толкает материал. Проверьте:

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

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

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

Смоделируйте потерю питания управления или прерывание выполнения. Проверьте:

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

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

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

Введите временное перекрытие между соседними состояниями машины. Проверьте:

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

Внесите возмущения процесса или нереалистичные значения датчиков. Проверьте:

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

1. Асинхронная аварийная остановка (E-stop) под нагрузкой
2. Отказ датчика и проверка отказоустойчивости
3. Восстановление после сбоя питания
4. Механический тайм-аут и отсутствие подтверждения
5. Состояния гонки в последовательности
6. Аналоговое отклонение и нарушение ПИД-регулирования

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

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

Шаблон тайм-аута — одна из простейших защитных структур, которая приобретает реальную ценность в SITL. Он превращает ситуацию «привод должен был уже сдвинуться» в наблюдаемое состояние ошибки.

Ниже приведен компактный пример тайм-аута выдвижения цилиндра. Точный синтаксис зависит от платформы, но логика управления стандартна.

Язык: Ladder Diagram (LD)

// Логика ошибки тайм-аута привода цилиндра |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

Что делает эта ступень

• `CMD_Extend` запускает условие тайминга при подаче команды на выдвижение.
• `Limit_Retract` не активен означает, что цилиндр больше не находится в безопасном исходном положении (в зависимости от философии устройства).
• `Limit_Extend` не активен означает, что подтверждение выдвижения еще не получено.
• `Fault_Delay` отсчитывает допустимое окно перемещения.
• Когда таймер завершается без подтверждения выдвижения, устанавливается `Fault_Cyl_Ext_Timeout`.

Почему SITL важен здесь

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

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

В этом разница между написанием тайм-аута и его проверкой.

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

Если цель — продемонстрировать серьезную работу по управлению, документируйте каждое смоделированное упражнение, используя эту структуру:

Требуемая структура доказательств

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

Пример: «Команда на выдвижение цилиндра выдана, пока время выбега конвейера составляло 1,8 с».

Пример: «Добавлено разрешение нулевой скорости конвейера и ошибка тайм-аута выдвижения».

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

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

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

В рамках предоставленных фактов о продукте, OLLA Lab предлагает:

• Веб-редактор логики с контактами, катушками, таймерами, счетчиками, компараторами, математическими функциями, логическими операциями и ПИД-инструкциями
• Режим симуляции для выполнения логики, переключения входов и наблюдения за выходами без физического оборудования
• Панель переменных для мониторинга тегов, I/O, аналоговых значений, ПИД-переменных и состояния сценария
• 3D/WebXR/VR симуляции, которые соединяют логику управления с поведением оборудования
• Рабочие процессы проверки цифровых двойников для тестирования логики на реалистичных моделях машин
• Лабораторные работы на основе сценариев в производстве, водоснабжении/водоотведении, ОВК, химии, фармацевтике, складской логистике, пищевой промышленности и коммунальных услугах
• Пошаговые инструкции по сборке с целями, отображением I/O, философией управления, блокировками и этапами проверки
• ИИ-поддержку через GeniAI, позиционируемую как коучинг и корректирующую поддержку внутри учебного процесса

Ограниченное утверждение

OLLA Lab может помочь инженерам отрепетировать задачи проверки, которые трудно безопасно организовать на реальных системах:

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

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

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

Что может поддерживать SITL

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

Что все еще требует отдельного рассмотрения

• Деятельность по жизненному циклу функциональной безопасности согласно IEC 61508
• Проектирование и верификация функций безопасности (SIF)
• Оценка рисков на конкретном объекте
• Анализ отказоустойчивости оборудования
• Испытания и проверка установленной системы

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

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

Хороший стартовый кейс в OLLA Lab — это конвейер с дивертером или сценарий ведущий/ведомый насос с:

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

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

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

Статья основана на методологиях VDI 3693, стандартах IEC 61131-3 и внутренних данных Ampergon Vallis по моделированию (2025-2026 гг.).

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)