Открытые стандарты и архитектуры цифровых двойников
Специфика моей деятельности связана с имитационным моделированием технологических объектов и процессов (как сейчас модно говорить – цифровые двойники, оптимизация, тренажеры для обучения персонала). И конечно в этом деле постоянно сталкиваюсь с задачей сетевого обмена информацией и синхронизацией данных, как при реализации многопользовательского режима так и при организации сетевого обмена между отдельными моделями. И вот наблюдаю интересную картину – некоторые производители цифровых двойников и тренажеров используют стандарты для этого всего (например OPC UA, IEEE 1516, DDS (Data Distribution Service), MQTT, CAPE-OPEN, xAPI) , а некоторые – делают самоделки, причем закрытые. Особенно меня удивляют товарищи, создающие эти самые самоделки, ни с чем не совместимые и абсолютно закрытые, только для того, чтобы потом с этими самоделками являться “единственным поставщиком” скажем так, требуя при этом совместимости со своими велосипедами, да еще и являются организациями – которые сами-же и проверяют совместимость стороннего ПО со своими-же велосипедами. Жуть в общем.
Почему это плохо и почему открытые стандарты и архитектуры в области имитационного моделирования – это хорошо?
Давайте рассмотрим хороший пример – промышленная автоматизация, конкретнее, семейство Unified Architecture (OPC UA) (спецификация, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них [https://ru.wikipedia.org/wiki/OPC_UA] или Modbus. Заказчик может выбрать любого поставщика, все оборудование практически совместимо между собой в рамках обмена данными по OPC UA, я могу выбрать любые контроллеры, любые SCADA-системы и все гарантированно будет работать. Причем эти правила игры нужны и удобны всем – и производителям ПО и железа, так и пользователям.
Давайте рассмотрим еще один пример – IEEE 1516. Основная идея стандарта – проста и понятна – если компания заказывает цифровые двойники или тренажеры у различных поставщиков – должна быть возможность их объединения в единую систему. Данный стандарт напрямую относится к имитаторам, направлен на построение систем распределенной имитации (протоколы, рекомендованные методы управления и обратной связи, системная архитектура и т.д.). Я как-то писал о нем на Хабре (https://habr.com/ru/articles/509504/). Распределенное моделирование (имитация) – технология обмена данными между тренажерами по локальным или глобальным вычислительным сетям. Это позволяет обеспечить совместную работу отдельных имитаторов как одной управляемой системы моделирования или имитации. Концепция распределенного моделирования опирается на использовании высокоуровневой архитектуры (HLA). Практически стандарт IEEE 1516 определяет архитектуру путем использования единого API (программного интерфейса приложений). Отправными постулатами стандарта являются:
- простые «монолитные» имитационные модели не могут удовлетворить потребности профессиональных пользователей;
- все возможные сферы применения имитационного моделирования заранее неизвестны;
- должны быть предусмотрены возможности произвольного комбинирования отдельных имитаторов в сложные имитационные системы;
- архитектура распределенного моделирования должна быть максимально открыта для будущих технологий моделирования и имитации.
На данный IEEE 1516 является абсолютным стандартом для взаимодействия тренажеров и имитаторов в военных приложениях, что обусловлено жесткими требованиями совместимости с имитаторами, разрабатываемыми и используемыми Министерством обороны США, НАТО, а также вооруженными силами РФ. В настоящее время IEEE 1516 находит все большее применение и в гражданской сфере, при разработке имитаторов для тренировки персонала сложных технических систем, в авиации, космонавтике, транспорте и т.д.
Приведенные стандарты OPC UA и IEEE 1516 на самом деле из совершенно различных областей, и их не совсем правильно сравнить “лоб в лоб”, но всё-таки, я это сделаю, иначе трудно показать преимущества от их использования вместо велосипедов.
Давайте начнем с OPC UA — спецификации, определяющей передачу данных в промышленных сетях и взаимодействие устройств в них. Поскольку тренажеры очень часто имитируют место оператора (SCADA-системы), а там в свою очередь OPC UA является де-факто “стандартом”. Основные возможности OPC UA:
- Стандартные интерфейсы и базовый стек обмена (в т.ч. через двоичное кодирование и JSON)
- Пользовательские типы данных (созданные на основе определений XML), Поддержка создания информационных моделей на основе стандартных определений XML
- Шифрование (OpenSSL, mbedTLS и др.), контроля доступа, ведения журнала, SecureChannel на основе TCP
- Поддержка добавления и удаления узлов и ссылок во время выполнения.
- Поддержка подписок (уведомления об изменении данных и событиях)
- Поддержка асинхронных запросов на обслуживание
- Режим реального времени (через UDP-многоадресную рассылку, Ethernet, MQTT)
- Настраиваемый быстрый путь доставки в реальном времени и т.д.
Фактически OPC UA может работать сразу в двух архитектурах – и как классический “клиент-сервер” и по модели “издатель – подписчик”
OPC UA имеет множество коммерческих и открытых (opensource) реализаций, множество примеров, имеет реализации на всех основных языках программирования и достаточно прост в реализации практического его использования.
Часто слышу мнение что OPC UA это “медленный” обмен… так вот нет …. на рисунке ниже приведен разброс по задержкам при использовании OPC UA.
Вообще в сети есть множество примеров, что при использовании операционных систем реального времени и “OPC UA PubSub over TSN” удавалось получать синхронизации менее 5 наносекунд причем при числе синхронизированных узлов в сети свыше нескольких сотен.
Пример использования OPC UA для организации многопользовательского режима в тренажере буровой установки Уралмаш БУ 5000/320 ЭУК-Я. https://lcontent.ru/product/burovaya-ustanovka-5000-320-er-euk/
Процесс тестирования математической модели – вывод данных и аналитика скорости обмена на ПО UAExpert (https://www.unified-automation.com/products/development-tools/uaexpert.html)
IEEE 1516 также является достаточно скоростным, более сложным и работает только на модели “издатель – подписчик”, но при этом еще и определяет общую архитектуру и строгие правила. Список совместимых программных инфраструктур для поддержки группы международных стандартов семейства IEEE 1516-2010:
- RRTI (“Russian RTI”) https://rusbitech.ru/products/system‑connect/rrti/
- pRTI 1.3, 1516 and 1516e from Pitch Technologies.
- MAK RTI 1.3, 1516 and 1516e from Mak Technologies
- RTI NG Pro 1.3, 1516 and 1516e from Raytheon
- OpenSource RTI Portico
- OpenSource RTI CERTI
- OpenSource RTI Open‑RTI
Изображение с сайта https://rusbitech.ru/products/system-connect/rrti/
Дополнительно поддержка новой версии данного стандарта (IEEE 1516-2010 / HLA Evolved ) включает ряд технических изменений, в том числе:
• Динамические связи (Dynamic Link Compatibility) — это означает, что федерации могут переключаться между используемыми RTI без перекомпиляция/перекомпоновка их приложения.
• Модульные FOM (Modular FOMs) — позволяют разработчикам федерации разбивать свою объектную модель на отдельные файлы (называемые модулями FOM). Тогда каждой федерации нужно знать только о FOM Используемые модули. Например, если определенным средством 3D-просмотра можно управлять с помощью пользовательского взаимодействия, тогда взаимодействие можно превратить в модуль FOM. Затем этот модуль может использоваться всеми федерации, которые хотят управлять средством 3D-просмотра; Федераты, не желающие управлять средством 3D-просмотра никогда не нужно знать, что модуль существовал в первую очередь.
• Снижение скорости обновления (Update Rate Reduction) — позволяет федерациям сообщать RTI, что они могут обрабатывать только обновления данных ниже определенной ставки. Это позволяет федерациям с ограниченной частотой обновления участвовать в загруженных федерации, не снижая скорости.
• Лучшая отказоустойчивость (Better Fault Tolerance) — HLA теперь имеет механизм уведомления федераций, когда другой Federate отключается от сети. Это значит, что когда что-то пойдет не так, все быстро поймут что пошло не так.
• API веб-служб (WEB Services API, WSDL) — стандарт HLA теперь определяет описание веб-службы.
Поэтому оба стандарта позволяют быстро синхронизировать практически неограниченные по размеру модели, могут создавать распределенные системы, фактически ограниченные только здравым смыслом)
Ну и вот пожалуйста – мой проект по реализации IEEE 1516 на GITHUB’е – https://github.com/maximum2000/OpenRTI_Unity
Пример использования IEEE 1516 для организации синхронизации математической модели на различных вычислительных серверах тренажера буровой установки Уралмаш БУ 5000/320 ЭУК-Я. https://lcontent.ru/product/burovaya-ustanovka-5000-320-er-euk/
DDS (Data Distribution Service, Служба распространения данных) для систем реального времени является стандартом межмашинного взаимодействия Object Managment Group, целью которого является обеспечение масштабируемых, оперативных, надежных, высокопроизводительных и совместимых обменов данными с использованием шаблона «издатель — подписчик». DDS удовлетворяет потребности приложений, связанных с управлением воздушным движением, умных сетей энергоснабжения, автономных средств передвижения, робототехники, логистики, энергоснабжения, медицинского оборудования, симуляции и тестирования, космонавтики и обороны, интернета вещей, а также других приложений, требующих обмена данных в реальном времени.
Для тренажерных систем DDS является аналогом HLA/IEEE1516.
Необходимость создания более реалистичных и сложных сред моделирования и симуляции (M&S), а также расширения спектра передаваемых данных, требует чрезвычайно высокой пропускной способности при низких задержках и совместном использовании данных в реальном времени через географически распределенные распределенные системы и сети. Это сочетается с необходимостью предоставления решений с открытой архитектурой, которая может обеспечить возможность повторного использования и взаимодействия между моделями и тренажерами/симуляторами:
особенности DDS : Совместимость между различными реализациями DDS (разные производители) на уровне протокола., Синхронизация данных с альтернативными источниками, высокая производительность – Поддержание производительности по мере увеличения масштаба моделирования. Требования к данным с низкой задержкой. Приоритизация и распределение данных в режиме реального времени. Безопасность, Конфиденциальность, ,Поддержка элементов динамического моделирования, Отказоустойчивость.
Таким образом стандарт службы распределения данных (DDS) OMG для систем реального времени все чаще используется для удовлетворения требований к распределению данных в реальном времени в крупномасштабных высокораспределенных тренажерных системах.
Ну и в заключении несколько “живых примеров” :
Обсуждаем также в образовательном сообществе в Digital Learning https://t.me/dl_vr_in_digitallearning и https://t.me/dl_hard
