Аннотация

Цифровой двойник (DT) - это «живая» сущность, которая предлагает потенциал для мониторинга и улучшения функциональности взаимосвязанных сложных инженерных систем (CES). Однако отсутствие подходов для гибкого подключения существующих систем и их данных ограничивает использование DT. В этой статье разрабатывается новая структура проектирования DT, которая использует онтологии для обеспечения совместной эволюции с CES путем сбора данных с точки зрения разнообразия, скорости и объема на протяжении жизненного цикла актива. Эта структура была успешно протестирована на примере коробки передач вертолета и мобильной роботизированной системе в течение всего их жизненного цикла, демонстрируя адаптивность DT без необходимости изменения архитектуры данных.

Keywords

Digital twins, Design method, Ontology

1. Введение и современное состояние

Цифровой двойник (DT) - это цифровое представление физического объекта, которое можно использовать для описания его свойств, состояния и поведения с помощью имитации, анализа и моделирования 1. Представление о DT заключается в создании полностью автономной системы, которая может собирать информацию о своей работе (например, производстве) и моделировать ее эффекты; DT может поддержать любое решение, которое будет принято в отношении объекта 2. У DT был целый ряд применений. Bilberg and Malik 3 представляют сборочную линию, управляемую роботом и человеком. Tao и др. 4 предлагают управление техническим состоянием на основе DT для ветряных турбин. Stark и др. 5 используют тестовую среду ячеек умных фабрик для исследования ключевых факторов для разработки и эксплуатации DT. Schleich et al. 6 описывают эталонную модель, основанную на концепции форм модели кожи для DT. DT собирает информацию о конструкции, производстве и эксплуатации, стремясь с минимальными различиями представить реальный актив. Это способствует принятию различных типов решений 2. DT в значительной степени полагаются на сбор и хранение обширных данных, связанных с жизненным циклом продуктов, использующих технологии IoT. Это часто достигается с помощью платформ PLM или ERP, которые могут охватывать весь жизненный цикл продукта 7. Однако, структурирование данных и обеспечение возможности их использования на протяжении жизненного цикла активов по-прежнему остается серьезной проблемой, поскольку онтологии вызывают интерес. По данным Zhu et al. 8, онтологии широко используются в контекстном моделировании, поскольку они не зависят от языков программирования и позволяют проводить контекстные рассуждения. Erkoyuncu et al. 9 представляют адаптивную операционную поддержку с использованием метода дополненной реальности с учетом контекста (AR). Старк и др. 10 использовать онтологию в контексте PLM для улучшения устойчивой разработки продукта. Abramovici et al. 7 предлагают платформу управления семантическими данными для разработки и постоянного изменения конфигурации интеллектуальных продуктов и систем. Также представлена обширная литература по вычислительным онтологиям, охватывающая логику описания, широко используемую для определения онтологий, таких как язык веб-онтологий 11.Старк и др. 5 подчеркивают необходимость дальнейшего развития связи между существующими системами зрелых предприятий DT и их данными. Tomiyama et al. 2 утверждают, что механизм обратной связи, в частности, от модели «как есть» к модели продукта, еще недостаточно изучен. Билберг и Малик 3 также поднимают вопрос о будущих потребностях в работе по бесшовной интеграции различных модулей с минимальным ручным вмешательством. Несмотря на то, что DT используются в разных контекстах, ограниченное исследование оценивает, как DT и его архитектура могут приспособиться к изменениям, произошедшим с активом в течение его жизненного цикла. Отсутствие подходов к адаптивности - одна из основных причин, препятствующих промышленному внедрению DT. Интеграция программного обеспечения в DT сегодня достигается с использованием стандартных форматов обмена данными 5. В этой статье утверждается, что это может оказаться невозможным для эволюционирующих DT, которые требуют изменений программного обеспечения из-за модификаций объекта на протяжении его жизненного цикла. Следовательно, еще предстоит решить несколько исследовательских задач:

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

В этой работе предлагается основанный на онтологии подход к проектированию архитектур данных DT для семантической связи данных и моделей для представления объекта.
Задача исследования: как спроектировать архитектуру данных DT, адаптируемую к изменениям в ее программном обеспечении и активе на протяжении их жизненного цикла?

2. Обзор систем для адаптивных DT

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

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

Последствия упомянутых изменений различны для различных вариантов управления данными DT. Децентрализованные подходы (рис. 1.a) включают репозитории данных для каждой программной системы. Следовательно, они более избыточны и безопасны, но требуют гораздо больше усилий для распространения изменений. Вместо этого централизованные подходы (рис. 1.b) лучше управляют изменениями данных, хотя они могут быть менее избыточными. Они используют центральный репозиторий для управления и обслуживания данных для каждого программного обеспечения по запросу. Централизованные репозитории требуют меньше усилий при внедрении нового программного обеспечения (необходимо создать только один интерфейс). Хотя, если новое программное обеспечение предполагает изменения в архитектуре данных репозитория (например, новый столбец в существующей реляционной базе данных), тогда все равно потребуется изменить все существующие интерфейсы. Это решается подходами к общему языку (рис. 1.c), которые также поддерживают преимущества централизации.
Fig. 1. DT data architures: Decentralised, centralised and ontology-based.
По сравнению с другими общими языками (например, языком структурированных запросов - SQL) онтологии предлагают дополнительные преимущества. Во-первых, они семантически организуют данные в соответствии с областями знаний (KD). Таким образом, данные DT могут использоваться с одинаковым смыслом как для программных систем, так и для пользователей. Во-вторых, онтологии основаны на допущении «открытого мира». Поскольку необъявленные данные не подразумеваются как несуществующие, изменения данных могут распространяться легче, поскольку интерфейсы подготовлены для приема новых схем данных. В-третьих, онтологии могут предоставлять возможности логического вывода для хранимых данных, предлагая дополнительные возможности для анализа существующих данных. Эти возможности вывода могут быть интегрированы посредством использования интерфейсов между различным программным обеспечением DT. Такие интерфейсы могут быть либо общими (например, стандартные механизмы вывода), либо специальными для конкретных задач (например, высокочастотные хранилища больших данных).

3. Основанный на онтологиях фрэймворк для проектирования адаптивных DT.

Среда проектирования определяет шаги для создания или обновления онтологий так, чтобы разнообразное программное обеспечение DT могло взаимодействовать друг с другом, используя общий язык. Такой язык должен описывать любые KD, которые необходимо учитывать в жизненном цикле актива. Кроме того, он также должен включать уникальные ссылки для каждого объекта, который должен быть частью актива. Поэтому данная структура проектирования состоит из двух основных этапов (рис. 2). Первый, который проводится только один раз, позволяет однозначно декларировать любую возможную часть актива, в том числе те, которые должны быть изменены в течение жизненного цикла актива. Второй этап позволяет сгенерировать интерфейсы для каждого нового программного обеспечения DT, которое будет включено. Они могут включать новую информацию о KD жизненного цикла существующих или новых активов. На этом этапе фиксируются требования к изменению дизайна и разрабатывается подходящая архитектура данных DT. Для количественной оценки модификаций основанных на онтологии архитектур данных используются следующие определения:
(1) разнообразие (количество атрибутов и / или отношений, которые необходимо изменить / обновить),
(2) объем (количество лиц, которые необходимо изменить или обновить, когда присвоение новых атрибутов / отношений) и
(3) скорость (количество интерфейсов для обновления в связи с развитием актива)
Fig. 2. Ontology Design Framework: Ontologies in asset KDs over time.

3.1. Этап 1: описание актива для адаптивного DT

Чтобы разнообразное программное обеспечение DT могло согласованно обмениваться данными, необходимо объявить уникальные ссылки для каждого возможного объекта (например, компонента или датчика), который является частью актива. Таким образом, можно отслеживать изменения (например, замену) в течение жизненного цикла актива. Этот этап включает в себя следующие шаги: Шаг 1. Определите все возможные иерархические уровни, из которых может состоять актив, и объявите их как классы. Шаг 2: Объявите все необходимые иерархические отношения для корреляции этих классов. Шаг 3. Объявите все необходимые атрибуты для определения временного характера частей активов (например, выбытия). Шаг 4: Определите стандарт для наименования каждого объекта, чтобы он мог иметь уникальные ссылки (например, запасные части). Хотя элементы онтологии могут быть изменены, количество атрибутов и отношений, назначенных для каждого класса, не должно меняться. Если это так, каждый раз, когда часть актива изменяется, любое существующее или новое программное обеспечение DT может отслеживать это. Следовательно, дополнительная информация об активе и его частях должна быть выделена в отдельные онтологии, как описано на этапе 2.

3.2. Этап 2: проектирование динамического поведения DT

На этапе 2 основное внимание уделяется гибкости проектирования и вариантам внедрения адаптивности в архитектуру данных DT в результате изменений в активе. Чтобы поддерживать предположение об «открытом мире» онтологий, необходимо учитывать два аспекта основанных на онтологии данных: темпоральность и иерархию. Временной атрибут / взаимосвязь включает временную информацию об активе (например, дату изготовления). Иерархический атрибут / отношение - это такой, который относится к конкретной категории элемента актива (например, компонент или система), как объявлено на Этапе 1. Если каждый атрибут или взаимосвязь, которые являются временными или иерархическими, поддерживаются в отдельном классе онтологии, то эти классы могут быть разделены друг с другом, сохраняя при этом свои смысловые связи. Таким образом, разные интерфейсы могут по-разному обрабатывать классы онтологий, сохраняя при этом согласованность данных. Следующие шаги предполагают эти аспекты для объяснения метода генерации изменяемых онтологий, чтобы данные можно было совместно использовать и обновлять последовательно в течение срока службы актива. Эти шаги запускаются каждый раз, когда программное обеспечение DT вводится или обновляется:
Шаг 1: Объявите данные для обмена нового / обновленного программного обеспечения как атрибуты и отношения онтологии. Это отражает требования к конструкции для адаптивности цифрового двойника на основе данных, которыми необходимо обмениваться.
Шаг 2: Если все они объявлены в существующих онтологиях, сразу сгенерируйте новый интерфейс. В противном случае перейдите к следующему шагу. Шаг 3. Определите все «отсутствующие» атрибуты и отношения из существующих онтологий и составьте список классов, содержащих те, которые не пропущены.
Шаг 4: Если все атрибуты и отношения «отсутствуют», перейдите к шагу 6. ​​В противном случае перейдите к шагу 5.
Шаг 5: Для каждого «отсутствующего» атрибута и / или отношения:
Шаг 5.1: Перечислите все возможные классы из шага 3 которому может быть присвоен атрибут / отношение «отсутствующий».
Шаг 5.2: Если «отсутствующий» атрибут / отношение является временным, то сгенерируйте новый класс, назначьте ему новый класс и отношение к классам, перечисленным на шаге 5.1.
Шаг 5.3: Если атрибут / отношение «отсутствующий» является иерархическим, присвойте его всем возможным классам, перечисленным в шаге 5.1. Если эти классы уже включают иерархические атрибуты или отношения, продублируйте классы, разделив их.
Шаг 5.4: Если атрибут / отношение «отсутствует» не соответствует ни одному из вышеперечисленных, присвойте его всем возможным классам, перечисленным в шаге 5.1.
Шаг 5.5: Если в результате предыдущих шагов есть более одного потенциального класса, который нужно объявить / изменить, перейдите к шагу 7. В противном случае перейдите к шагу 8.
Шаг 6: Для всех «отсутствующих» атрибутов и / или отношений:
Шаг 6.1: Создавайте новые классы, группируя атрибуты и отношения, чтобы отделить каждый временной и иерархический аспекты.
Шаг 6.2: Убедитесь, что каждый новый класс включает отношение к классу из схемы иерархической онтологии (этап 1).
Шаг 6.3: Убедитесь, что каждый новый класс, отдельные лица которого могут быть изменены без изменения его ссылки на иерархического индивидуума (этап 1), имеет временной атрибут или взаимосвязь.
Шаг 6.4: Если в результате предыдущих шагов необходимо объявить более одного потенциального класса, перейдите к шагу 7. В противном случае перейдите к шагу 8.
Шаг 7: Существующие варианты объявлений классов должны быть оценены на основе их влияния на архитектура данных:
Шаг 7.1: Для каждого нового / измененного объявления класса рассчитайте его изменения в разнообразии, скорости и объеме.
Шаг 7.2: Выберите объявление класса, которое лучше соответствует архитектуре данных DT с точки зрения разнообразия, скорости и объема.
Шаг 8: Объявите все новые / измененные классы онтологий, обновите их базы знаний и сгенерируйте новый интерфейс программного обеспечения.

4. Тематические исследования: редуктор вертолета и роботизированная система.

4.1. Демонстрация коробки передач вертолета

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

Реализация структуры началась с определения общего языка для описания актива и его состава в иерархическом порядке. Рис. 3 (a) показывает иерархию активов, классы и отношения для этапа 1. Этап 2 был сосредоточен на новом отверстии, которое необходимо было изготовить на кольце, и был формализован KD отверстия. Шаг 1 определил свойства отверстия, включая объект (рис. 3 (а)). Поскольку никакая существующая схема не может представить новый KD отверстия (шаг 2), все недостающие классы и свойства были идентифицированы (шаг 3). Поскольку ни существующие классы, ни атрибуты не присутствовали для описания отверстия (шаг 4), процесс проектирования перешел к шагу 6, который должен создать новые классы (например, GeometricalHole) с необходимыми атрибутами, включая временные атрибуты (например, hasDesigned-DateTimeUpdated) и отношения к существующему классу. Поскольку никакого другого правдоподобного объявления класса с его атрибутами не было идентифицировано (шаг 7), существующая онтология была обновлена ​​с последующей реализацией программного интерфейса (шаг 8). Веб-программное обеспечение, которое записывает производственные операции, выполняемые с активом, было создано для обновления компонента (например, добавления отверстия). Это действие создало нового человека для отверстия в конкретном компоненте и передало его в программное обеспечение для проектирования, чтобы обновить его 3D-модель через плагин.
Fig. 3. Ontology Design Framework: Cases of study.
На рис. 4 показан окончательный результат работы над подключаемым модулем для программного обеспечения для проектирования, который понимает изменения в данных DT, внесенные другим программным обеспечением, с использованием логического вывода и автоматически генерирует новую версию представления компонента для отражения совместной эволюции с активом. Это гарантирует, что последнее изменение (например, 3D-модель) будет автоматически включено. В результате обновленное DT легко доступно для других программных систем, например. мониторинг состояния, который приводит к обратной связи с физическим активом. С точки зрения разнообразия, архитектура на основе онтологий требует двух новых отношений и шести новых атрибутов (разнообразие = 8). Подход SQL потребует двух новых таблиц для добавления внешних ключей (2 отношения) и 6 новых столбцов (атрибутов). Хотя число «разнообразия» аналогично, подход, основанный на онтологии, потребует меньших усилий для применения этих изменений, поскольку он не требует модификации уже существующих схем. С точки зрения объема объем изменяемых данных в обоих случаях одинаков. Однако, когда количество лиц, подлежащих изменению из-за обновлений в объявлении класса (таблица в SQL), увеличивается, подход, основанный на онтологии, упростит согласованность данных. Что касается скорости, количество интерфейсов, которые необходимо изменить (скорость для распространения изменений), меньше (быстрее), поскольку для этого потребуется только обновить интерфейс CAD (скорость = 1), а не интерфейсы CAM и CAD (как в SQL сближение, скорость = 2).
Fig. 4. Co-evolution of DT with its physical asset in the gearbox example.

4.2. Роботизированная система

Второй пример демонстрирует (рис. 3b), как существующее DT лабораторной мобильной роботизированной системы адаптируется с использованием разработанной структуры. Окончательный результат (рис. 5) показывает, как предлагаемая структура улучшает отслеживание, мониторинг и навигацию по существующему DT. Существующая система состоит из реальных роботов и DT, состоящего из симулятора и навигационного программного обеспечения, которое работает с симулятором. Целью адаптации является разработка и реализация системы слежения на основе камеры, которая позволит навигационному программному обеспечению работать с реальными роботами, обеспечивая преобразования между системами координат роботов, требуемые навигационным программным обеспечением. Также предусмотрена система мониторинга, которая позволяет в реальном времени отслеживать траектории роботов во времени. Таким образом, адаптация включает установку верхней камеры, разработку программного обеспечения для отслеживания, которое обнаруживает маркеры роботов и вычисляет их глобальные положения, а также разработку модуля мониторинга для визуализации траектории.
Fig. 5. Ontology-based communication in the mobile robotic case study.

5. Выводы и будущая работа.

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

Благодарности
Исследование было частично поддержано проектом DigiTOP, финансируемым EPSRC (EP / R032718 / 1), и Словенским исследовательским агентством (P2-0270). Работа велась совместно с Университетом Крэнфилд, Сити, Лондонским университетом и Университетом Любляны. Авторы также признательны Babcock International за поддержку этой работы. Данные, лежащие в основе этого документа, доступны по адресу https://doi.org/10.17862/cranfield.rd.12136074.

References
1
M. Helu, A. Joseph, T. Hedberg
A Standards-Based Approach for Linking as-Planned to as-Fabricated Product Data
CIRP Annals - Manufacturing Technology, 67 (2018), pp. 487-490
ArticleDownload PDFView Record in ScopusGoogle Scholar
2
T. Tomiyama, E. Lutters, R. Stark, M. Abramovici
Development Capabilities for Smart Products
CIRP Annals - Manufacturing Technology, 68 (2019), pp. 727-750
ArticleDownload PDFView Record in ScopusGoogle Scholar
3
A. Bilberg, A. Malik
Digital Twin Driven Human-Robot Collaborative Assembly
CIRP Annals - Manufacturing Technology, 68 (2019), pp. 499-502
ArticleDownload PDFView Record in ScopusGoogle Scholar
4
F. Tao, M. Zhang, Y. Liu, A.Y.C. Nee
Digital Twin Driven Prognostics and Health Management for Complex Equipment
CIRP Annals - Manufacturing Technology, 67 (2018), pp. 169-172
ArticleDownload PDFView Record in ScopusGoogle Scholar
5
R. Stark, C. Fresemann, K. Lindow
Development and Operation of Digital Twins for Technical Systems and Services
CIRP Annals - Manufacturing Technology, 68 (2019), pp. 129-132
ArticleDownload PDFView Record in ScopusGoogle Scholar
6
B. Schleich, N. Anwer, L. Mathieu, S. Wartzack
Shaping the Digital Twin for Design and Production Engineering
CIRP Annals - Manufacturing Technology, 66 (2017), pp. 141-144
ArticleDownload PDFView Record in ScopusGoogle Scholar
7
M. Abramovici, J. Go¨bel, H. Dang
Semantic Data Management for the Development and Continuous Reconfiguration of Smart Products and Systems
CIRP Annals - Manufacturing Technology, 65 (2016), pp. 185-188
ArticleDownload PDFView Record in ScopusGoogle Scholar
8
E. Zhu, P. Ong, A.Y.C. Nee
A Context-Aware Augmented Reality System to Assist the Maintenance Operators
International Journal of Computer Integrated Manufacturing, 28 (2) (2015), pp. 213-225
CrossRefView Record in ScopusGoogle Scholar
9
J.A. Erkoyuncu, I. Fernández, M.D. Mura, R. Roy, G. Dini
Improving Efficiency of Industrial Maintenance With Context Aware Adaptive Authoring in Augmented Reality
CIRP Annals - Manufacturing Technology, 66 (1) (2017), pp. 465-468
ArticleDownload PDFView Record in ScopusGoogle Scholar
10
R. Stark, A. Pfortner
Integrating Ontology Into PLM- Tools to Improve Sustainable Product Development
CIRP Annals - Manufacturing Technology, 64 (1) (2015), pp. 157-160
ArticleDownload PDFView Record in ScopusGoogle Scholar
11
M. Krötzsch, S. Frantisek, I. Horrocks
Description Logics
IEEE Intelligent Systems, 29 (1) (2015), pp. 12-19
Google Scholar