Решения IIoT | 6 промышленных коммуникационных решений IoT

Сказать, что задача выбора вашего промышленного Интернета вещей ( Интернет вещей ) Коммуникационная инфраструктура - это очень сложное мероприятие, будет мягко сказано. Оценка множества коммерчески доступных решений требует больших затрат времени и средств. Попробуйте загрузить и оценить несколько решений для каждого типа инфраструктуры, и вы быстро окажетесь в центре проекта, на выполнение которого у нескольких инженеров уйдет добрых шесть месяцев. Мы все были там, и я хочу помочь вам сэкономить драгоценное время!

Цель этого сообщения - познакомить вас с популярными коммерчески доступными решениями для инфраструктуры IIoT - AMQP, CoAP, DDS, RTI Connext DDS, MQTT и ZeroMQ - и выделить возможности каждого решения. Будут применяться шесть следующих областей оценки:архитектура, шаблоны связи, транспорты, тип данных и фильтрация, качество обслуживания и безопасность.

Щелкните здесь, чтобы загрузить версию PDF для печати. ​​

1. Архитектура

В зависимости от архитектурного паттерна данной инфраструктуры связи, приложения с логическим подключением (показанные на рис. 1 ниже) будут использовать разные приложения для связи с другими приложениями в инфраструктуре. Двумя основными архитектурами, используемыми в сегодняшних решениях промежуточного программного обеспечения, являются (1) одноранговые и (2) звездообразные архитектуры на основе брокера.

1. Одноранговые архитектуры позволяют приложениям напрямую обмениваться данными друг с другом без необходимости отправлять данные промежуточному элементу. Эти архитектуры по своей природе более эффективны при доставке данных, поскольку только отправляющие и принимающие приложения расходуют ресурсы ЦП для завершения передачи. Следовательно, только приложения, у которых есть данные, и приложения, которым они нужны, будут потреблять циклы ЦП; Таким образом достигается эффективное распределение обработки в зависимости от требований приложения. Другое преимущество одноранговой архитектуры состоит в том, что детерминированная доставка данных намного более достижима, поскольку отсутствует «посредник», обрабатывающий данные между приложениями производителя и потребителя.

Рис. 1. Архитектурные схемы для различных протоколов IoT.

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

2. Шаблоны общения

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

• Опубликовать / подписаться :Приложение (подписчик) запрашивает данные 1 раз, а затем все последующие обновления данных «отправляются» подписчику. Нет необходимости постоянно запрашивать обновления данных.
• Запрос / ответ / RPC ( Удаленный вызов процедур ):Приложение-отправитель отправляет запросы, а приложение-ответчик отвечает на запрос.
• В очереди ( или точка-точка ):Данные отправляются на сервер, который будет хранить информацию в очереди. Затем данные могут быть либо извлечены из очереди, либо отправлены потребителям. В отличие от публикации / подписки, каждый фрагмент данных передается только одному принимающему приложению.
• Один ко многим :Возможность иметь несколько приложений-получателей, получающих одни и те же данные из одного источника.
• Многие к одному :Возможность получать данные из многих источников в одно приложение-получатель.

3. Транспорт и маршрутизация / мосты

Большинство решений связующего ПО поддерживают TCP в качестве основного протокола связи. Использование TCP обеспечивает надежную доставку данных с помощью встроенного механизма надежности, присущего TCP. Это может быть идеальным для определенных потоков данных, которые требуют надежности, но являются избыточными и добавляют ненужные накладные расходы к простым данным датчиков, которые не требуют надежной доставки. Некоторые решения IoT, такие как ZeroMQ и DDS, также поддерживают другие виды транспорта, такие как разделяемая память. Следует отметить использование транспорта UDP для DDS. Поскольку реализация надежности встроена в DDS, она не требует надежного транспорта под ней. Это позволяет приложениям выбирать, какие потоки данных являются надежными, а какие - наиболее эффективными.

Маршрутизация данных между транспортом и через WAN - это то, что все эти решения тем или иным образом обеспечивают. В современном мире, когда корпоративные системы, использующие технологии ESB и Web, также должны получать доступ к некоторым данным в реальном времени, важно, чтобы промежуточное программное обеспечение связи также поддерживало подключение к этим технологиям. Из-за этого вы увидите маршрутизацию и мосты в качестве основного компонента для промежуточного программного обеспечения распределенных систем.

4. Тип данных и фильтрация

Способ инкапсуляции и представления данных в сети также уникален для данной инфраструктуры. Некоторые решения отправляют только необработанные байты данных, и задача приложения - сериализовать и десериализовать данные. Другие отправляют только текстовые / строковые данные, так что информация может быть представлена ​​в формате XML или JSON. Этот сценарий очень распространен сегодня в веб-технологиях, но может быть очень неэффективным, потому что при каждой отправке данных пакет также содержит описание данных, иногда увеличивая размер пакета более чем в 3 раза по сравнению с исходным размером. Пакеты большего размера увеличивают использование полосы пропускания, а также увеличивают загрузку ЦП как на отправляющей, так и на принимающей сторонах передачи. Поместите посредника в середину этого, и вы также удвоите количество пакетов на проводе.

Другие решения, такие как DDS, позволяют использовать строго типизированные данные, которые однозначно сериализованы и десериализованы промежуточным программным обеспечением. Схема отправляется отдельно, чего нельзя сказать о XML или JSON, и поэтому вы не платите штраф за сообщение (или образец). Это также становится очень важным для фильтрации аспектов. Допустим, вы настраиваете одного издателя с множеством подписчиков. Некоторым подписчикам могут потребоваться все данные, но некоторым подписчикам потребуется только часть данных. Без строго типизированного решения для данных вашим приложениям придется управлять всеми этими функциями фильтрации, а это еще больше кода, который вам нужно написать. С такими решениями, как DDS, где информация о типе строго определена, промежуточное программное обеспечение может управлять всей фильтрацией за вас. Меньше кода =более счастливые разработчики :). Фактически, RTI Connext DDS имеет дополнительные функции для обеспечения этой фильтрации на стороне записи при передаче данных, что приводит к меньшему использованию полосы пропускания на проводе и меньшей обработке ЦП в приложениях, которым не требуется фильтрация данных.

5. Качество обслуживания

Не все данные одинаковы. Что это значит? Что ж, некоторые данные в распределенном приложении реального времени представляют собой потоковую передачу данных с датчиков. В большинстве случаев данные такого типа не требуют гарантированной доставки. Для данного датчика вы можете просто заботиться о том, чтобы заданный крайний срок доставки данных был соблюден или, что более важно, не соблюден. Другими данными могут быть данные о тревоге / событии. Эти данные не имеют периодичности по част

[1] [2] 下一页