Платформы и транспорты:выбор лучшего решения для подключения к IIoT

Построение инфраструктуры распределенной системы в формирующейся сегодня среде промышленного Интернета вещей (IIoT) может быть, мягко говоря, непростой задачей. Если вы разработчик или системный архитектор, вы знаете, что существует множество инструментов и протоколов, которые можно использовать для перемещения данных в распределенном приложении. Не говоря уже о возможности создания собственного решения непосредственно на сокетах TCP или UDP. Разве не было бы замечательно, если бы большая часть работы, которую необходимо было сделать, прежде чем вы могли принять решение о вашей следующей инфраструктуре, уже была сделана за вас?

Знаешь что? Работа выполнена, и теперь она доступна, чтобы помочь вам принять это решение. Вы, должно быть, спросите:«Кто проводил все это исследование, и не является ли оно предвзятым со стороны какой-либо компании, стремящейся продать свое собственное решение?» Хорошей новостью является то, что исследование было проведено независимым консорциумом Industrial Internet Consortium (IIC). Он был проведен беспристрастно и беспристрастно, и полученная информация теперь доступна вам.

Полный отказ от ответственности:Да, я работаю в компании, которая предоставляет инфраструктуру для промышленного Интернета, но я ни в коем случае не говорю, что наше решение является лучшим решением. Настоящий ответ на вопрос:«Какое решение лучше?» "Это зависит от обстоятельств".

Ответ зависит от того, что вам нужно от инфраструктурного решения:

• Вам просто нужно отправить байты данных из точки A в точку B?
• Вам нужна надежная доставка данных?
• Нужна ли вам какая-либо ориентированная на данные осведомленность, чтобы инфраструктура могла предоставлять некоторые эффективные решения по доставке для более интеллектуального решения?
• Какую часть обработки данных вы хотите передать инфраструктуре?

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

О Консорциуме промышленного Интернета (IIC)

IIC была создана в 2014 году некоторыми очень крупными игроками в сфере промышленного Интернета. Компании-основатели (Cisco, Intel, AT&T, IBM и GE) намеревались создать организацию, ориентированную исключительно на потребности промышленных Интернет-приложений. Сейчас в консорциум входит более 250 компаний, как больших, так и малых. Результаты этого консорциума включают набор документов, в которых описываются потребности и потенциальные решения для этих типов промышленных Интернет-приложений. Руководящий документ IIC Industrial Internet Connectivity Framework (IICF) идеально подходит для того, чтобы помочь вам определить лучшее решение для рыночных примеров. В дополнение к различным документам, они также установили испытательные стенды, которые будут использоваться, чтобы доказать способность различных технологий соответствовать различным примерам реального рынка. Информацию о доступных документах и ​​рыночных испытательных стендах можно найти на веб-сайте IIC.

Доставка данных:транспорты и фреймворки

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

Рисунок 1. Стек IIC Connectivity Framework.

Практически каждый, читающий этот документ, видел подобный стек подключения, но стек IIC имеет одно четкое различие:уровни транспорта и инфраструктуры.

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

Таблица 1. Возможности транспорта и инфраструктуры

Можете ли вы создать распределенное промышленное Интернет-приложение с помощью транспорта? да. Можете ли вы создать распределенное промышленное Интернет-приложение с помощью фреймворка? да. Одно лучше другого? Настоящий ответ:«Это зависит от обстоятельств». От требований вашего приложения зависит, какое решение лучше всего подходит для вашей инфраструктуры. В оставшейся части этого поста мы рассмотрим несколько из этих фреймворков и транспортов, чтобы вы могли решить, какая технология подходит для вашего приложения.

Транспорт

Сегодня доступно множество решений для обмена данными между приложениями. В IICF вызываются транспорты, которые используют стандартные интерфейсы IP-сокетов UDP или TCP. Если вашему приложению требуется надежная передача данных, разработчик выберет TCP из-за его возможностей, ориентированных на соединение, и надежных механизмов. Для более простого соединения и ненадежной передачи данных будет выбран протокол UDP из-за простоты использования и многоадресной доставки. В течение многих лет большинство сетевых приложений использовали эти базовые интерфейсы для отправки и получения данных. Все возможности, предоставляемые транспортными средствами более высокого уровня (перечисленные в таблице 1), должны быть встроены непосредственно в приложение. При рассмотрении транспортов более высокого уровня, таких как DDS-RTPS, CoAP, MQTT, HTTP и OPC-UA Bin, мы действительно будем рассматривать только детали для CoAP и MQTT. Транспорты DDS-RTPS, HTTP и OPC-UA Bin в основном связаны напрямую с вышележащими структурами DDS, Web Services и OPC-UA соответственно. Возможности этих транспортов будут обсуждаться в рамках последующего обсуждения фреймворка.

MQTT

Давайте посмотрим на транспортную телеметрию очереди сообщений (MQTT). Опять же, MQTT указан здесь как транспорт, поскольку он не обеспечивает и не реализует модель данных для приложений. Он только предоставляет буфер, на основе которого приложения должны формировать свои данные для отправки и получения. Его основная цель, для которой он был создан, указана прямо в его названии:Телеметрия. Наличие устройства или приложения в полевых условиях для подключения к серверному облаку или удаленному месту обработки и передачи данных в него. Этот транспорт отлично подходит для таких вещей, как домашний шлюз Интернета вещей или менеджер набора развернутых устройств. Как показано на рисунке 2, основная архитектура MQTT основана на брокере.

Рис. 2. Архитектура брокера MQTT.

В этой архитектуре все удаленные клиенты отправляют свои данные брокеру MQTT, и брокер отвечает за отправку своих данных всем клиентам, которые запросили эти данные. Эта архитектура на основе брокера упрощает отправку и получение данных в слабосвязанной манере, но она не позволяет поддерживать высокодетерминированные промышленные приложения с малой задержкой. В качестве транспортного средства MQTT занимает свое место в общем ландшафте распределенных промышленных приложений. Ниже приводится инструмент, который вы можете использовать, чтобы определить, следует ли использовать MQTT для своего следующего или текущего проекта. Вот пять вопросов «да» или «нет». Если вы ответили «да» на три или более из этих вопросов, тогда MQTT - правильный выбор для вас.

Вопросы по MQTT

1. Вы думаете о своем приложении как о сборе данных?
2. Существует ли слабая связь между устройствами?
3. Разве совместимость не рассматривается?
4. У вас много маленьких устройств?
5. Является ли программное обеспечение незначительной проблемой?

MQTT - единственный транспорт, указанный в документе IICF, который на самом деле не привязан к каркасу более высокого уровня. По этой причине мы разделили его как транспорт. Теперь давайте взглянем на платформы, перечисленные в документе IIC.

Фреймворки

Как упоминалось ранее, различие между каркасом и транспортом заключается в том, что каркас включает в себя возможность поддержки и обеспечения соблюдения модели данных, которая используется приложениями, участвующими в структуре. Из четырех названных фреймворков, OPC-UA, OneM2M, DDS и Web Services, мы рассмотрим только первые три. Веб-службы - это очень хорошо известная структура с множеством онлайн-ссылок, которые можно найти для исследования, и по этой причине мы не будем рассматривать ее в

[1] [2] 下一页