Введение

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

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

Предыстория

К нам в компанию обратился клиент — представитель службы эксплуатации аэропорта уездного города N с запросом на устранение проблем в автоматическом режиме работы пассажирского посадочного моста.

Система управления позволяет заранее обучиться положениям моста для различных типов самолётов (учитывая высоту и расположение входной двери). Оператор выбирает тип самолёта, и мост должен автоматически занять нужное положение. Однако проблема в том, что мост либо не доезжает до заданной точки, либо переезжает её.

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

Первичный анализ

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

Вызов сервисных специалистов производителя оказался невозможен.

Клиент предоставил запасные ПЛК и ЧМИ-панель для тестов, и работа переместилась в офис.

Сложности при моделировании

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

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

Решение: цифровой двойник

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

Цель: воспроизвести поведение системы без изменения оригинальной логики ПЛК, всё должно работать максимально приближённо к реальному объекту.

Реализация

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

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

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

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

Выводы

Создание цифрового двойника позволило:

• Безопасно тестировать и анализировать поведение системы без ограничений реального объекта

• Выявить причины некорректной работы автоматического режима

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

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