Вопрос или проблема
Мы находимся в процессе реализации очень крупного IoT-проекта, и из-за огромного объема данных, который будет поступать в долгосрочной перспективе, я задумываюсь о том, чтобы обеспечить решение, которое я проектирую, чтобы оно могло справляться с этой нагрузкой.
В связи с этим я рассматриваю возможность использования цифровых двойников (ок, МНОГО МНОГО цифровых двойников) как.middleware слой, что позволит нашему экземпляру Complex Rule Engine запрашивать/мониторить цифровые двойники, а не поток данных с сенсоров.
Одним из дополнительных требований, которые мы рассматриваем, является возможность запуска цифрового двойника на менее мощном комплексе оборудования/инфраструктуры на уровне предприятия, а затем наличие той же модели, работающей в облаке/центре обработки данных. (Это соображение помогает уменьшить задержку и добавить резервирование в случае потери связи с различными объектами.)
Но большинство обсуждений о цифровых двойниках, которые я вижу, предполагают, что цифровые двойники имеют ограниченное количество атрибутов/характеристик (как правило, менее пары десятков), которые они “реплицируют”.
Наша же схема, с другой стороны, будет иметь (в долгосрочной перспективе) тысячи (возможно, близкие к десяти тысячам) атрибутов, которые будут мониториться (некоторые физические, некоторые производные) для каждого экземпляра.
Моя первоначальная мысль заключалась в том, чтобы создать наше собственное решение, используя исключительно настраиваемую/гибкую модель данных в реляционной базе данных (возможно, бесплатную версию, но с полной поддержкой), но, понимая, что создание пользовательского решения не всегда является лучшим путем, я осознаю, что использование готового решения/опции может быть лучшим вариантом, особенно с учетом того, на каком этапе жизненного цикла программного обеспечения мы находимся.
Есть ли какие-либо варианты (предпочтительно с открытым исходным кодом), которые будут соответствовать нашим требованиям/сложности, или нам следует просто создать собственное решение с нуля?
Спецификация OCF — это то, что вам нужно, она обеспечит будущее ваше IoT и сделает все универсально доступным, один универсальный механизм доступа ко всем данным устройств IoT. Часть стандарта включает демократизированный набор измерений и других типов данных в JSON-файлах, к которым вы можете внести свой вклад, если у вас есть что-то совершенно новое, или просто использовать его в своих системах, если это только для вас.
Это ОТКРЫТОЕ ИССЛЕДОВАНИЕ от Samsung, Google, Intel и других, чтобы избавиться от абсурда наличия тысяч “умных” или IoT-экосистем, из-за чего каждому продукту требуются специальные лицензии и программное обеспечение для поддержки других продуктов.
Это также означает, что если что-то предоставляет позицию, вы можете визуализировать это, даже в 3D-модели, которую вы, вероятно, также сможете распространять с использованием спецификации OCF. Таким образом, 3D-клиент может просто искать сервер, совместимый с OCF, и с правами доступа, после подключения, стримить все, что хочет говорить, и что видит сервер. Чем больше вещей вы захватите и откроете на данном сайте, тем более полную картину вы сможете нарисовать.
Ответ или решение
Создание масштабируемой архитектуры для разработанного решения по цифровым двойникам (Digital Twins), которая способна обрабатывать тысячи атрибутов и справляться с высокой нагрузкой, является вызовом, особенно в контексте IoT. Вот детальный подход к решению вашей задачи:
1. Архитектура цифровых двойников
Начнём с основ. Цифровые двойники служат виртуальным представлением физических объектов или систем и могут содержать неограниченное количество атрибутов. Чтобы ваша архитектура справлялась с тысячами атрибутов, необходимо:
-
Модульная структура: Создайте структуру, которая позволит добавлять атрибуты без необходимости в полной переработке модели. Используйте подход "плагины" для добавления новых данных по мере их появления.
-
Иерархическая организация: Разработайте иерархическую модель, где каждый уровень может содержать набор атрибутов, связанных с физической единицей. Это поможет управлять сложностью и упрощает доступ к данным.
2. Выбор платформы
Хотя вы рассматриваете создание собственного решения, стоит обратить внимание на существующие решения. Есть несколько открытых платформ, которые могут удовлетворить ваши потребности:
-
Kaa IoT Platform: Эта платформа предоставляет фреймворк для управления данными IoT и подходит для построения цифровых двойников с большим количеством атрибутов. Она поддерживает масштабируемость и может быть развернута как в облаке, так и локально.
-
Eclipse IoT: Это набор проектов с открытым исходным кодом, которые могут помочь вам при разработке решений IoT. Он включает всё необходимое для работы с данными, правилами, а также расширяемостью.
-
OneM2M: Это стандарт для M2M и IoT, позволяющий разработать приложения, совместимые с существующими устройствами. Можно адаптировать его для поддержки сложных цифровых двойников.
3. Согласованность между платформами
Важно, чтобы ваша система для локальных и облачных приложений была согласованной:
-
Соответствие стандартам: Использование специфических стандартов, таких как OCF (Open Connectivity Foundation), поможет обеспечить совместимость и доступность данных из разных источников. Это позволит не только интегрировать различные датчики, но и создавать единый интерфейс для доступа к данным.
-
Локальные хранилища данных: Имейте на месте локальные базы данных для хранения критически важных данных и обеспечения работы в условиях потери связи. Элементы, такие как Apache Kafka в качестве промежуточного слоя для передачи данных, также могут помочь синхронизировать данные, когда связь будет восстановлена.
4. Обработка и анализ данных
С учетом большого объема данных необходимо внедрить эффективные механизмы их обработки:
-
Параллельная обработка: Используйте распределенные вычисления для обработки данных (например, Apache Spark или Flink), которые способны обрабатывать потоки данных и выполнять сложные вычисления в реальном времени.
-
Использование ИИ и машинного обучения: Модели машинного обучения могут помочь в предиктивной аналитике, извлекая значимые паттерны и взаимосвязи из ваших данных, что особенно полезно с учетом большого числа атрибутов.
5. Интерфейсы и APIs
Для обеспечения гибкости взаимодействия между компонентами системы используйте RESTful APIs и GraphQL, которые позволят вам динамически управлять атрибутами и легко интегрироваться с другими системами.
Заключение
Оптимальным будет использование существующих открытых решений с возможностью адаптации, которые позволят сократить время разработки и снизить риск ошибок. Ваша архитектура должна быть гибкой и поддерживать масштабируемость, чтобы справляться с будущими требованиями, поскольку количество атрибутов может только увеличиваться.
Разработка и внедрение подобной архитектуры потребует взаимодействия различных дисциплин, от программирования до системного моделирования. Убедитесь, что у вас есть доступ к квалифицированным специалистам, которые смогут помочь в этом процессе, и активно используйте существующие сообщества разработчиков для обмена знаниями и получения поддержки.