Облачные технологии в интернете вещей

Облачные технологии в интернете вещей разделяются на облачные вы- числения (Cloud Computing) и туманные вычисления (Fog Computing).

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

Облачные вычисления − это модель обеспечения сетевого доступа к об- щему фонду конфигурируемых вычислительных ресурсов – серверам, системам хранения данных, приложениям и сервисам − как вместе, так и по отдельности.

«Облако» строится на основе центров обработки данных (ЦОД).

 

Туманные вычисления – это разновидность облачных сервисов, располо- женных не в «облаке», а в окружающей среде, например, на соседнем сервере. Туманные вычисления реализуются беспроводными сенсорными сетями, кото- рые объединяют в IoT (рис. 6.15).

Туманные вычисления дополняют облачные за счет передачи части рабо- ты с «облака» «туману» при реализации задач, требующих значительных ком- пьютерных ресурсов.

 

Пользователи

 

Рис. 6.15. Туманные и облачные вычисления в концепции интернета вещей

Таким образом, если говорить об интернете вещей не на уровне «умного дома», а, например, на уровне «умного города», то IoT реализуется в виде трех- уровневой иерархической структуры. Верхний уровень занимают тысячи об- лачных ЦОД, предоставляющих ресурсы, необходимые для выполнения серь- езных, например аналитических, программных приложений IoT. Уровнем ниже располагаются десятки тысяч распределенных управляющих ЦОД, в которых содержится «интеллект» Fog Computing («Обработка тумана»), а на нижнем уровне находятся миллионы вычислительных устройств умных вещей.

 

6.4.5. Протоколы интернета вещей

Для взаимодействия вещей и пользователей в IoT необходимы специаль- ные протоколы. Рассмотрим их в соответствии с последовательными участками установления связи между элементами IoT:

• СУ (вещи) и пользовательское устройство (компьютер, планшет, мо- бильный телефон и т.д.) устанавливают друг с другом связь, назовем этот уча-

сток взаимодействия «Device-to-Device» (D2D);

 

• собранные данные передаются в серверную инфраструктуру (облако), назовем этот участок взаимодействия «Device-to-Server» (D2S);

• серверная инфраструктура должна совместно использовать данные, имея возможность передавать их обратно устройствам, программам анализа

или пользователям. Назовем этот участок взаимодействия «Server-to-Server».

Известны следующие протоколы реализации взаимодействия элементов интернета вещей согласно выделенным участкам:

• DDS: быстрая шина для интегрирования интеллектуальных устройств (D2D);

• CoAP: протокол для передачи информации о состоянии узла на сервер (D2S);

• MQTT: протокол для сбора данных устройств и передачи их серверам (D2S);

• XMPP: протокол для соединения устройств с пользователями, частный случай D2S-схемы, когда пользователи соединяются с серверами;

• STOMP: протокол для обмена сообщениями между устройством и сер- вером, реализованными на разных языках и платформах (D2S);

• AMQP: система организация очередей для соединения серверов между собой (S2S).

Каждый из перечисленных является протоколом реального времени и мо- жет варьироваться в зависимости от приложения интернета вещей. Известны десятки вариантов реализации перечисленных протоколов на практике. Объ- единяет их общая идея организации взаимодействия – схема «из- дай/подпишись» (publish/subscribe), которая позволяет соединять тысячи устройств.

DDS (Data Distribution Service) – реализует шаблон публикации-подписки для отправки и приема данных, смен состояний и команд среди конечных уз- лов. Узлы-издатели создают информацию – «topic» (темы, разделы: температу- ра, местоположение, давление и т.д.) и публикуют шаблоны в виде реляцион- ной модели данных (рис. 6.16). Узлам, предназначенным для таких разделов, DDS прозрачно доставляет созданные шаблоны и реализует прямую шинную связь между устройствами. В качестве транспорта используется протокол UDP (User Datagram Protocol), предназначенный для передачи дейтаграмм.

С помощью DDS реализуется многоадресная система между вещами и пользователями. Передача сообщений между взаимодействующими вещами и пользователями производится по методу «запрос-ответ». В отличие от других протоколов, в которых в явном виде надо указывать, что, кому и когда переда- вать, протокол DSS является анонимной моделью взаимодействия – вещи не знают своих пользователей, а пользователи не знают, какие конкретно сенсор- ные устройства являются источниками информации. Такая анонимность явля- ется основой масштабируемости и самоорганизации БСС, на базе которой по- строен интернет вещей, – при замене вещи или пользователя не надо переписы- вать связующее программное обеспечение.

 

 

Вещь 1 (издатель)

 

Пользователь (подписчик)

 

Вещь 3 (подписчик)

 

Вещь

 

Пользователь (издатель/подписчик)

Topic 1

 

Topic 2

(издатель)

 

Вещь (издатель)

 

Вещь 2 (издатель)

 

 

Пользователь (издатель/подписчик)

Рис. 6.16. Схема работы DDS-протокола интернета вещей

CoAP (Constrained Application Protocol) работает на прикладном уровне и предназначен для передачи данных по линиям с ограниченной пропускной спо- собностью. CoAP был разработан на основе протокола HTTP с учетом низкой мощности и малого потребления энергии СУ интернета вещей. В отличие от протокола HTTP, который является текстовым, CoAP – бинарный протокол, что уменьшает размер его служебных данных. Транспортируется посредством UDP. CoAP организован в два слоя: транзакций и «Request/Response» («За-

прос/Ответ).

Слой транзакций обрабатывает обмен сообщениями между конечными точками. Сообщения обмена на этом слое могут быть четырех типов:

• «Confirmable» – требует подтверждения;

• «Non-confirmable» – не требует подтверждения;

• квитирование – подтверждает получение «Confirmable» сообщения;

• «Reset» – указывает на то, что «Confirmable» сообщение было получено, но контекст, подлежащий обработке, отсутствует.

Слой «Запрос/Ответ» представляет модель взаимодействия Кли- ент/Сервер для манипулирования ресурсами и передачи. «Вещь » обычно «игра- ет роль» сервера. По запросу клиента (приложения пользователя) устанавлива- ется флаг наблюдения, и сервер начинает отвечать, передавая измерения состо- яний сенсорных устройств (вещей).

Протокол CoAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS.

MQTT (Message Queue Telemetry Transport) осуществляет сбор данных от множества узлов и передачу их на сервер. В качестве транспорта – протокол TCP. MQTT предназначен для телеметрии и дистанционного мониторинга.

Протокол MQTT основывается на модели издатель-подписчик с исполь- зованием промежуточного сервера – брокера. Брокер решает задачу формиро- вания очередей сообщений и их приоритезации. Таким образом, вся передавае-

 

мая информация разделяется по направлениям на разные каналы, число кото- рых соответствует количеству издателей/подписчиков.

Все сенсорные или исполнительные устройства посылают данные только брокеру и принимают данные тоже только от него. То есть когда один клиент, так называемый издатель, передает сообщение M на определенную тему T, то все клиенты, которые подписываются на тему Т, получают это сообщение М. Например, три клиента подключены к брокеру, клиенты B и С подписываются на topic «Temperature» (рис. 6.17). В какое-то время, когда клиент А передает значение «30» на topic «Temperature» (рис. 6.17, а), сразу после его получения брокер передает это сообщение к подписавшимся клиентам (рис. 6.17, б).

Также в MQTT предусматривается три выбора надежности обмена сооб- щениями, которые обеспечиваются тремя уровнями качества обслуживания (QoS, Quality of Service):

• QoS0 – сообщение передается только один раз и не требует подтвер- ждения;

• QoS1 – сообщение отправляется до тех пор, пока не будет получено подтверждение об его успешной доставке;

• QoS2 – при однократной передаче сообщения используется четырехсту- пенчатая процедура подтверждения доставки.

 

Клиент C                      Клиент B                 Клиент C                      Клиент B

  

Подписаться на topic «Temperature»

“Temperature = 30”

 

Клиент A

Клиент A

а)                                                         б)

Рис. 6.17. Схема работы протокола MQTT

XMPP (Extensible Messaging and Presence Protocol) – расширяемый прото- кол обмена сообщениями и идентификационной информацией. XMPP давно

 

используется в сети Интернет для передачи сообщений в режиме реального времени. В XMPP применяется текстовый формат языка разметки XM, благо- даря чему протокол подходит для использования в сетях IoT. XMPP работает поверх архитектур издатель-подписчик и клиент-сервер и используется для ад- ресации устройств в небольших сетях (адресация вида [e-mail]). В качестве транспорта применяется протокол TCP.

С помощью XMPP, например, возможно подключение домашнего термо- стата к Web-серверу с целью получения к нему доступа с телефона. Сильными сторонами этого протокола являются безопасность и масштабируемость, что делает его идеальным для приложений Интернета вещей с ориентацией на по- требителя.

Таким образом, на участке сети между СУ и брокером чаще всего приме- няются протоколы – CoAP, MQTT и XMPP. Выбор конкретного протокола за- висит от условий реализуемости сети. Можно отметить, что XMPP нашел свое применение в системах климат-контроля и освещения, а также используется для адресации устройств в небольших персональных сетях. MQTT поддержива- ет качество обслуживания и проверку доставки сообщений. Протокол MQTT обеспечивает такие приложения, как мониторинг утечек и контроль за окружа- ющей средой на территориях опасного производства. Другими приложениями для MQTT могут быть контроль потребления энергии, управление светом и да- же интеллектуальное садоводство. CoAP предназначен для устройств с ограни- ченными ресурсами и для сетей с низким энергопотреблением. Известно при- менение протокола в системах датчиков умного дома.

Для сетей, использующих оборудование различных платформ, можно ре- комендовать простой протокол передачи сообщений STOMP.

STOMP (Simple Text Oriented Message Protocol) – простой протокол обме- на сообщениями, предполагающий широкое взаимодействие со многими язы- ками, платформами и брокерами. Так, STOMP согласует взаимодействие серве- ра, описываемого на одном языке программирования, и клиентом, программное обеспечение которого разработано на другом языке. Поддерживает большое количество совместимых клиентских библиотек, связанных языков.

Если протокол MQTT обеспечивает «сквозную» связь, как от брокера к сенсорным узлам, так и от брокера к серверу, то протокол STOMP ориентиро- ван только на взаимодействие брокера с сервером.

Для соединения серверов между собой (S2S) разработан протокол AMQP. Протокол AMQP (Advanced Message Queuing Protocol) – усовершенство- ванный протокол организации очереди сообщений. Как следует из названия, протокол обслуживает исключительно очереди – пересылает транзакционные

сообщения между серверами. Работает поверх TCP. AMQP основан на трех понятиях:

• Сообщение – единица передаваемых данных.

• Брокер – приемник всех сообщений. Брокер распределяет сообщения в одну или несколько очередей. При этом в брокере сообщения не хранятся.

Механизмы работы брокера могут быть разными (зависит от версии про- токола):

 

• fanout – сообщение передается во все прицепленные к брокеру очереди;

• direct – сообщение передается в очередь с именем, совпадающим с ID маршрута;

• topic – сообщение передается в очередь по теме подписки.

В очереди сообщения хранятся до тех пор, пока они не будут забраны

пользователем. Клиент всегда забирает сообщения из одной или нескольких очередей.

Для эффективного использования протокола в интернете вещей необхо- димо правильно выбрать версию AMQP-брокер.

AMQP применяется главным образом в обмене деловыми сообщениями. В интернете вещей AMQP наилучшим образом подходит для реализации ана- литических функций на базе серверов.

Итак, краткий обзор протоколов интернета вещей позволяет классифици- ровать их по назначению (табл. 6.1, рис. 6.18).

Беспроводные сенсорные сети считаются одной из самых перспективных технологий XXI века. Недорогие и «умные» сенсоры, объединенные в беспро- водную сеть, подключенную к интернету (интернет вещей), предоставляют ши- рокий набор услуг контроля и управления телами, домами, предприятиями, ав- томобилями и т. д.

 

Устройство (вещь)

 

Пользователь

Устройство (вещь)

 

Брокер

   

Устройство

(вещь)

Устройство (вещь)

Пользователь

Брокер

 

а)                                                б)

 

Брокер

 

STOMP,

Сервер

Сервер                 Сервер

в)                                                 г)

Рис. 6.18. Протоколы взаимодействия вещей и пользователей в IoT

Таблица 6.1