Databus vs Database: 6 ключевых вопросов, которые должен рассмотреть каждый IIoT-разработчик

Industrial Internet of Things (IIoT) вводит многие новые концепции, часто опираясь на знакомые вычислительные принципы, но переформируя то, как системы работают. Среди них «databus» (шина данных) выделяется как базовый элемент.

Грядущая IIC эталонная архитектура v2 вводит новый паттерн «layered databus» (многослойная шина данных). Пока детали еще на рассмотрении, процесс документирования прояснил ключевые определения и лучшие практики.

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

Ключевые характеристики:

1. Приложения взаимодействуют с данными напрямую, без промежуточных оберток.
2. Инфраструктура понимает данные, позволяя селективную фильтрацию и продвинутый тулинг.
3. Инфраструктура применяет гарантии Quality-of-Service (QoS), такие как частота, надежность и безопасность.

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

Вопрос 1: Чем databus отличается от database?

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

Подробный ответ: Данно-ориентированность выражается через три измерения:

• Интерфейс: Данные сами являются первичным интерфейсом; нет искусственных оберток вроде сообщений или файлов.
• Понимание: Инфраструктура может интерпретировать данные, позволяя фильтрацию, поиск и интеграцию инструментов.
• Управление: Система применяет правила обмена данными, устанавливая единый источник истины и управляя жизненными циклами данных, схемами и CRUD-семантикой.

Реляционная база данных, например, предоставляет структурированный слой хранения, обеспечивающий согласованность и глобальный поиск. Она определяет «истину» системы, потому что сохраненные данные не могут быть повреждены или утеряны. Databus, с другой стороны, предоставляет виртуальное глобальное пространство данных, позволяя приложениям писать и читать потоки данных, пока middleware применяет правила QoS и доставляет только информацию, соответствующую критериям потребителя.

Вопрос 2: Действует ли databus как база данных, доступная через pub-sub интерфейс?

Краткий ответ: Нет. База данных подразумевает персистентное хранение; databus предлагает чисто виртуальное глобальное пространство данных, которое может или не может персистировать данные.

Подробный ответ: Рассмотрите контроллер перекрестка, подписывающийся на позиции транспортных средств в радиусе 200 м. Контроллер получает обновления, удовлетворяющие его QoS-ограничениям (например, < 0.01 с задержка, 100 обновлений/с). Databus может доставлять данные напрямую без хранения, хотя временное кэширование может происходить для соблюдения требований надежности.

Вопрос 3: Что значит, что участники напрямую взаимодействуют с данными?

В сообщения-ориентированном middleware приложения должны знать детали о пире, такие как схема и ожидаемые частоты обновлений, что добавляет связность и мешает повторному использованию. Databus абстрагирует эти детали; приложения читают из или пишут в пространство данных, используя CRUD-интерфейс, специфицируя только данные и QoS, которые им нужны. Инфраструктура обрабатывает обнаружение источников, фильтрацию, транспорт и гарантии.

Вопрос 4: Как работает селективная фильтрация в databus по сравнению с традиционным pub-sub?

Традиционный pub-sub просто пересылает сообщения подписчикам, часто не инспектируя полезные нагрузки. Даже content-filtered pub-sub полагается на простые селекторы, не способные выражать сложный QoS. Databus, напротив, позволяет подписчику задать детальные критерии (например, транспортное средство в пределах 200 м, движущееся > 10 м/с к перекрестку, 200 Гц обновлений). Middleware применяет эти ограничения у источника, троттлит, отбрасывает или буферизует данные для соблюдения контракта и гарантирует живость.

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

Вопрос 5: Чем databus отличается от CEP-движка?

Краткий ответ: Databus — это распределенный middleware, пересылающий данные на основе простых фильтров, в то время как CEP-движок — централизованный сервис, оценивающий сложные паттерны событий.

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

Вопрос 6: Что привело к созданию стандарта DDS и концепций databus?

Ранние последователи в робототехнике, обороне и системах крупномасштабной координации требовали надежности, низкой задержки и селективного обнаружения при отказе компонентов. Эти требования привели к стандарту DDS, который сегодня находит применение в здравоохранении, транспорте, умных городах и энергетике.

Чтобы узнать больше об интеллектуальном ПО, формирующем IIoT, скачайте нашу белую книгу, The Secret Sauce of Autonomous Cars.