Виды взаимодействия в Интернете вещей

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Введение

интернет вещь протокол виджет

В настоящее время активно развивается такое направление в области информационных технологий, как “Интернет вещей” - совокупность разнообразных приборов, датчиков, устройств, используемых ранее локально и автономно, объединённых в сеть посредством любых доступных каналов связи, использующих различные протоколы взаимодействия между собой и единственный протокол доступа к глобальной сети. В роли глобальной сети для интернет-вещей, в настоящий момент используется сеть Интернет.Общим протоколом является IP.

Переход к Интернету вещей, согласно исследованию Cisco, произошёл примерно в 2008-2009 годах. С этих пор количество устройств, подключённых к глобальной сети Интернет, превысило численность населения Земли. Число инноваций в этой области непрерывно растёт, что говорит об активном развитии Интернета вещей.

Следует различать понятия “Интернет вещей” и “интернет-вещь”.

Под интернет-вещью понимается любое устройство, которое:

имеет доступ к сети Интернет с целью передачи или запроса каких-либо данных,

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

имеет интерфейс для взаимодействия с пользователем.

Интернет-вещи имеют единый протокол взаимодействия, согласно которому любой узел сети равноправен в предоставлении своих сервисов. Каждый узел сети интернет-вещей предоставляет свой сервис, оказывая некую услугу поставки данных. В то же время узел такой сети может принимать команды от любого другого узла. Это означает, что все интернет-вещи могут взаимодействовать друг с другом и решать совместные вычислительные задачи.

Рисунок 1. Функциональная схема Интернета вещей

Интернет-вещи могут образовывать локальные сети, объединённые какой-либо одной зоной обслуживания или функцией. Например, сеть умного дома, состоящая из различных датчиков, может иметь доступ в Интернет и иметь возможность управления посредством веб-интерфейса. В то же время несколько “умных сетей” могут быть объединены в одну взаимосвязанную сеть мониторинга и управления системой пожаротушения города, а городские сети могут быть объединены глобальной сетью Интернет для общего доступа к информации об уровне пожарной безопасности в любом городе страны. Этот пример представляет собой частный случай территориально-распределённых сетей, развитию которых поспособствовала активная инновационная деятельность в области беспроводных сенсорных сетей за последнее десятилетие.

Беспроводные сенсорные сети - одно из активных направлений в области систем мониторинга-развивалось от локальных сенсорных сетей до территориально-распределённых, связанных с глобальными сетями Internetи GSM. В терминологии беспроводных сенсорных сетей часто встречается такое понятие, как “умная вещь”. С появлением Интернета вещей все умные вещи, имеющие доступ к сети Интернет, называют интернет-вещами.

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

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

Ещё одним шагом на пути к идее Интернета вещей была технология M2M (MachinetoMachine), совершенство и распространение которой позволило использовать её в любом мобильном устройстве, в том числе и узлах сенсорных сетей. Считается, что именно эта технология породила термин “Интернет вещей”, подразумевая под ним некую обособленную вычислительную среду, состоящую из устройств, самостоятельно взаимодействующих друг с другом и предоставляющих пользователю результаты своей совместной деятельности.

Интернет вещей в будущем может иметь огромное количество устройств. По прогнозам аналитиков, к 2020 году общее количество устройств, подключенных к Сети, составит от 12 до 50 миллиардов единиц. Поэтому в настоящее время является актуальным вопрос оптимальной организации Интернета вещей с учётом требований к быстродействию сети в целом, размеру используемыхданных для хранения и энергосбережению отдельных узлов сети.

Одним из вопросов организации Интернета вещей является разработка методов взаимодействия между:

интернет-вещами,

пользователями и интернет-вещами,

удалённым сервером и интернет-вещами.

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

Каждая интернет-вещь должна иметь интерфейс для связи с пользователем, который состоит из программной и визуальной части. Визуальная часть может использовать довольно большой объём памяти для хранения, что порождает проблему роста нагрузки на ресурсы сети в результате увеличения размера используемых данных Интернетом. Данная проблема решается в ходе выполнения основной задачи (достижения цели работы) путём разработки веб-приложения - конструктора виджетов, которое позволяет значительно сократить рост потребления ресурсов сети интернет-вещами и убрать линейную зависимость нагрузки от числа интернет-вещей в сети. Представленное решение также упрощает разработку пользовательских интерфейсов для интернет-вещей и предоставляет пользователю большую гибкость при взаимодействии с интернет-вещью, что представляет научную новизну в решении данной проблемы.

Целью данной работы является проведение исследования существующих методов взаимодействия в Интернете вещей между основными его составными, выявление проблем, связанных с ними и поиск оптимального их решения.

В данной работе даётся обзор методов взаимодействия в Интернете вещей, показываются существующие и прогнозируемые проблемы,предлагается решение рассматриваемых проблем с целью улучшить качество предоставляемых Интернетом вещей услуг.



1. Способы взаимодействия в Интернете вещей

В настоящий момент можно выделить 3 основных способа взаимодействия с интернет-вещами:

прямой доступ,

доступ через шлюз,

доступ через сервер.

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

Недостатки такого способа очевидны:

необходимость иметь фиксированный адрес в сети, что зависит от провайдера услуги связи с Интернетом таких вещей. Другим выходом из ситуации является использование алиаса (сетевого псевдонима IP-адреса), что требует постоянного обращения интернет-вещи к специальному серверу с запросом об обновлении сетевого адреса по псевдониму.

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

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

Недостатки такого подхода те же, что и в случае прямого доступа, но распространяются они на шлюз.

Доступ к интернет-вещам через сервер подразумевает наличие посредника между интернет-вещами и пользователем. Таким посредником является сервер, в основные функции которого входит:

приём сообщений от интернет-вещей и передача их пользователям,

хранение принятой информации и её обработка,

обеспечение пользовательского интерфейса с возможностью двустороннего обмена между пользователем и интернет-вещью.

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

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

1.1 Использование шлюза

В Интернете вещей шлюз используется не только для прямой связи интернет-вещей с пользователем, но и при использовании централизованного сервера.Шлюзы служат средством для объединения локальных сетей интернет-вещей с глобальной сетью и связью с сервером управления или конечным пользователем. Поскольку локальные сети интернет-вещей представляют собой в основном беспроводные сенсорные сети, то шлюзы, используемые в Интернете вещей, аналогичны используемым в территориально-распределённых сенсорных сетях.Существует несколько способов организации шлюзов.

Первый способ заключается в использовании компьютеров, которые имеют точку доступа к глобальной сети Интернет, и каждая из объединяемых сетей подключена к такому компьютеру. Основными недостатками такого подхода являются стоимость и громоздкость. Сенсорные сети состоят из миниатюрных датчиков и должны работать автономно, однако территориально-распределённая сенсорная сеть при таком подходе теряет свойство автономности, поскольку теперь она зависит от наличия электричества и точки доступа в Интернет на компьютере.

Второй способ заключается в использовании устройства-шлюза, позволяющего соединить сенсорную сеть с ближайшей проводной сетью, имеющей выход в Интернет. Такой проводной сетью, как правило, является Ethernet-сеть. Устройство имеет в себе приёмопередатчик, совместимый с объединяемой сенсорной сетью, порт для подключения к сети Ethernet и микроконтроллер, выполняющий функции преобразования пакетов одной сети в формат другой. Такой способ отличается меньшей стоимостью, чем первый и размер такого устройства небольшой, но оно нуждается в относительно высоком энергопотреблении из-за того, что стандартные проводные сети не рассчитаны на низкий уровень сигнала и потребления энергии. Также такое устройство не может гарантировать наличие точки доступа в ближайшей проводной сети.

Третий способ заключается в использовании устройства-шлюза, которое является полностью автономным и само предоставляет точку доступа к сети Интернет. Это возможно при использовании беспроводных технологий передачи данных. Устройство состоит из одного приёмопередатчика, совместимого с сенсорной сетью и второго - совместимого с той или иной глобальной беспроводной сетью, в область действия которой попадает сенсорная сеть. Такими сетями могут служить GSM или WiMAX. Использование сети GSM является более экономичным в плане энергопотребления.

Существуют также шлюзы, предоставляющие доступ сенсорным сетям к ближайшим сетям Wi-Fi для поиска точки доступа к сети Интернет.

Таким образом, если необходимо организовать полностью автономную территориально-распределённую сенсорную сеть, то следует использовать третий способ. Если же сенсорная сеть используется как часть какой-либо крупной проводной сети, то нет необходимости в её полной автономности и возможно использование первых двух способов.

Рисунок 2. Шлюз в территориально-распределённых сенсорных сетях

Чаще всего в Интернете вещей используется третий способ - шлюз, имеющий аппаратно-программные средства для работы в сетях ZigBee и GSM, а также имеющий возможность использования GPRS/EDGE канала для доступа в сеть Internet.В силу данной особенности и того, что локальные сети интернет-вещей обычно основаны на стеке протоколов ZigBee, наиболее часто используемым устройством является ZigBee-GSMшлюз.

ZigBee-GSM шлюз представляет из себя систему, состоящую из двух основных частей: узел сети ZigBee и узел сети GSM, соединённых последовательным интерфейсом UART. В качестве узлов этих сетей могут выступать встраиваемые модули. Такие модули разрабатываются различными компаниями, такими как Jennic, Digi для сетей ZigBee и Siemens, SierraWireless для сетей GSM. Встраиваемые модули выпускаются для конструкторских разработок, для создания автоматизированных систем и аппаратно-программных комплексов на их основе.

Ниже представлена упрощённая общая схема ZigBee-GSMшлюза.

Рисунок 3. Функциональная схема ZigBee-GSMшлюза

В настоящее время шлюзы в сенсорных сетях активно используются для интеграции и совместной работы различных технологий. За последние 4 года различными компаниями были разработаны всевозможные варианты шлюзов для сенсорных сетей, объединяющих в себе все современные беспроводные технологии, такие как Wi-Fi, WiMAX, GSM/GPRS, Bluetooth, GPS.

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

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

накопление информации;

включение или выход из режима сна GSM/GPRS модуля;

установка соединения с сервером;

передача информации;

переход в спящий режим или выключение.

Был проведён ряд исследований, где установлено, что GSM/GPRS устройства тратят от нескольких до десятков секунд на установление связи с сетью, а также, в случае использования TCP/IP стека, на получение IP-адреса и установление соединения с сервером. Соответственно, если необходимо использовать спящий режим, то время сна и накопления информации нужно взять сравнительно больше, чем время соединения устройства с сервером.

На кафедре вычислительных систем и сетей в лаборатории WiSeNetLabбыл разработан ZigBee-GSMшлюз, максимально удовлетворяющий критериям стоимости и энергопотребления. Это было достигнуто путём подбора компонентов для разрабатываемого устройства, в том числе и основных модулей, выбирая их по данным критериям. Была также разработана математическая модель энергопотребления ZigBee-GSMшлюза, позволяющая сконфигурировать его в соответствии с любыми требованиями к потреблению энергии.

1.2 Централизованный сервер как метод взаимодействия

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

модуль обработки информации,

базу данных для хранения собираемой информации,

интерфейс взаимодействия с интернет-вещами (некоторый протокол, поддерживаемый всеми вещами),

систему контроля пользовательского доступа к вещам, управления их иерархией, параметрами и функционалом.

Последний пункт может быть перенесён на отдельный сервер и вынесен в обособленную систему управления, отделяя друг от друга базу собираемых данных и базу данных управления вещами.

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

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

Управление интернет-вещами производится также через сервер. Пользователь отправляет команду на сервер управления, а он, в свою очередь, транслирует её адресату. Набор команд управления должен быть минимальным и общим для всех интернет-вещей для обеспечения полного отделения управления от данных. Это важное требование к интернет-вещам, поскольку позволяет значительно упростить обмен информацией между пользователями и вещами, а также сделать шаг на пути к стандартизации методов взаимодействия в Интернете вещей и созданию общего центра управления.

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

При использовании централизованного сервера управления, структуру сети (топологию) Интернета вещей можно рассматривать с двух сторон: реальная (физическая топология) и топология с учётом непрямых связей (логическая).

Физическая Топология Интернета вещей - звезда - все интернет-вещи или группы вещей соединены с сервером по отдельности.

Логическая же топология может быть абсолютно любой. Любые 2 вещи могут быть соединены как местным беспроводным каналом, так и внешним - через сервер управления, обеспечивая непрямую связь. Предоставление услуг одной вещью другой может быть как абсолютно прозрачным (вне зависимости от территориального расположения вещи), так и с разделением на 2 протокола для локальной сети и связи с удалённой вещью.

Рисунок 4. Физическая Топология Интернета вещей с использованием централизованного сервера

Беспроводная локальная сеть интернет-вещей может быть организована средствами протоколов ZigBee, Wi-Fi, Bluetoothи других протоколов беспроводной связи малой зоны действия, а связь с сервером управления может быть установлена посредством глобальной сети Интернет. При этом могут использоваться технологии GPRS, WiMAX, направленная радиопередача, проводные каналы связи.

ZigBee - наиболее часто используемый протокол для беспроводных сенсорных сетей.ZigBee -- это по сути не отдельный протокол, а спецификация сетевых протоколов верхнего уровня (уровня приложений и сетевого уровня), использующих сервисы нижних уровней -- уровня управления доступом к среде и физического уровня, регламентированных стандартом IEEE 802.15.4. ZigBee и IEEE 802.15.4 описывают беспроводные персональные вычислительные сети (WPAN). Спецификация ZigBee ориентирована на приложения, требующие гарантированной безопасной передачи данных при относительно небольших скоростях и возможности длительной работы сетевых устройств от автономных источников питания (батарей).

Основная особенность технологии ZigBee заключается в том, что она при малом энергопотреблении поддерживает не только простые топологии сети («точка-точка», «дерево» и «звезда»), но и самоорганизующуюся и самовосстанавливающуюся ячеистую (mesh) топологию с ретрансляцией и маршрутизацией сообщений. Кроме того, спецификация ZigBee содержит возможность выбора алгоритма маршрутизации, в зависимости от требований приложения и состояния сети, механизм стандартизации приложений -- профили приложений, библиотека стандартных кластеров, конечные точки, привязки, гибкий механизм безопасности, а также обеспечивает простоту развертывания, обслуживания и модернизации.



2. Виды взаимодействия в Интернете вещей

Интернет вещей представляет собой вычислительную сеть, имеющую

основные узлы - интернет-вещи,

серверы управления интернет-вещами,

пользовательские узлы - мобильные и персональные вычислительные устройства.

Таким образом, можно выделить 3 основных вида взаимодействий в Интернете вещей:

взаимодействие между интернет-вещами,

взаимодействие между пользователями и интернет-вещами,

взаимодействие между удалённым сервером и интернет-вещами.

2.1 Взаимодействие между удалённым сервером и интернет-вещами

Все интернет-вещи в большинстве своём используют радиочастотный канал данных, зачастую с весьма ограниченной пропускной способностью, несмотря на огромный объём передаваемых данныхв некоторых случаях. В то же время интернет-вещь имеет и жёсткие ограничения по вычислительным ресурсам. Это создаёт следующие ограничения для протокола обмена между вещью и концентратором данных (концентратор данных - сервер, шлюз или любое другое устройство, принимающее и маршрутизирующее или фиксирующее данные от интернет-вещи):

минимизация трафика,

максимальное исключение ошибок передачи данных итрансляции команд,

поддержка функции делегирования задачи другой вычислительной единице.

Протоколом сетевого уровня для существующих в настоящий момент интернет-вещей является IP, над которым возможно применение протоколов транспортного уровня со специальными модификациями. В разных источниках рассматривается также вопрос о замене протокола IPс целью улучшить алгоритм маршрутизации для обеспечения мобильности интернет-вещей (например, протоколыLocator/ID Separation Protocol (LISP) и Six/One).

Протокол LISPсозданкомпаниейCisco для разделения на две части функциональности, связанной с IP-адресами. Идентификаторы хостов и локаторы маршрутизации разделяются, и предусматривается установка туннельных маршрутизаторов, добавление LISP-заголовков в пакеты по мере их движения по сети.

Протокол Six/One,созданный компанией Ericsson, является альтернативой LISP и дополнением к протоколу IPv6.При таком подходе хосты получают постоянные IP-адреса, которые меняются лишь в старших битах, в зависимости от того, к какому провайдеру подключен хост в данный момент. Эти старшие биты подставляются автоматически, как только пакеты идут через нового провайдера.

На прикладном уровне существует ряд протоколов, разработанных специально для “умных вещей”. Наиболее известный и популярный среди них - протокол MQTT, разработанный компанией IBM.

2.1.1 Протокол MQTT

MQTT (MQ Telemetry Transport) - это протокол, поддерживаемый микроброкером Lotus Expeditor. MQTT представляет собой основанный на TCP/IP протокол обмена сообщениями publish/subscribe (издатель-подписчик), предназначенный для использования в сетях, требующих минимальных накладных расходов. Микроброкер - это маленький брокер сообщений (менее 2 МБ Java-кода), спроектированный для развёртывания на небольших специализированных устройствах, часто удалённых от корпоративного информационного центра.

Для публикации сообщений при помощи MQ Telemetry Transport требуется соединение c микроброкером Lotus Expeditor или другим сервером обмена сообщениями, поддерживающим протокол MQTT, например, WebSphere Message Broker. Для создания подключения к брокеру необходимо выполнить несколько шагов. Создаётся объект свойств MQTT, который затем передаётся фабрике создания клиента. Этот объект свойств предоставляет конфигурацию созданному экземпляру клиента. Одно из этих свойств - булев флаг (Boolean flag), указывающий, является ли клиентское приложение "клиентом без сохранения сеанса". Если значение флага - true, при каждом подключении клиент не будет знать о предыдущем соединении с брокером (например, о любых ранее сделанных подписках или об ожидающих доставки сообщениях). Если значение флага - false, состояние клиента при различных подключениях к брокеру остаётся прежним; например, клиентскому приложению не потребуется повторная подписка при каждом последующем переподключении. Кроме того, в этом случае клиент и брокер пытаются возобновить любой выполняющийся в данный момент обмен сообщениями (в зависимости от определённого для сообщений качества сервиса), прерванный при разрыве соединения. Для использования "клиента с сохранением сеанса" необходимо обеспечить реализацию интерфейса MqttPersistence. Включение реализации этого интерфейса обозначает для фабрики создания клиента, что клиентскому приложению требуется персистентная (надёжная) доставка сообщений. После настройки свойств мы получаем экземпляр MQTT-клиента из фабрики MQTT-клиента. Для создания экземпляра MQTT-клиента требуется несколько параметров, в том числе уникальный идентификатор клиента (client ID), IP-адрес и порт брокера, а также дополнительный объект MqttProperties, описанный ранее.

Идентификатор клиента идентифицирует каждого клиента брокеру. В первую очередь это гарантирует надёжную передачу сообщений и поддерживает состояние подписки при множественных подключениях и отключениях клиента. Важно заметить, что идентификатор каждого клиента, подключающегося в брокеру, должен быть отличен от других. Если два клиента попытаются выполнить подключение к брокеру с помощью одного и того же идентификатора клиента, предпочтение будет отдано последнему соединению, а более раннее будет принудительно отключено. Это сделано для того, чтобы обеспечить повторное подключение клиента к предыдущему соединению, которое не было полностью очищено. Идентификатор клиента может иметь длину до 23 символов.

После успешного подключения MQTT можно публиковать сообщения. Приложения выполняют публикацию через объект MQTT-клиента. Сигнатура метода для публикации сообщения - int publish(String, MqttPayload, byte, Boolean). Ниже подробно рассматриваются эти четыре параметра:

String. Тип параметра темы - строковой (string), и эта строка используется брокером для сопоставления публикации и интересов подписчиков (указываемых при помощи описанного ранее синтаксиса подписки на темы).

MqttPayload. Второй параметр - это объект MqttPayload. Объект MqttPayload содержит и данные приложения, и любые заголовки протокола для этой публикации. Предусмотрен сдвиг (offset), чтобы приложения могли определить, где в MqttPayload начинаются данные. Это обеспечивает доступ к нижележащему байтовому массиву без создания дополнительных копий после записи данных в сети. Кроме того, обеспечивается доступ для прямого манипулирования полезными данными после создания объекта и до передачи.

Byte. Третий параметр, byte, - это качество сервиса (Quality of Service, QoS) для этой публикации. У QoS три допустимых значения: 0, 1 или 2:

QoS, равное 0, означает, что публикатор и брокер пытаются выполнить однократную доставку сообщения, но не предпринимают шаги, кроме предусмотренных TCP/IP, чтобы убедиться в том, что сообщение доставлено. Этот уровень иногда называют "выстрелил и забыл", так как сообщение отправляется адресату без проверки получения.

При QoS, равном 1, доставка сообщения брокеру проверяется; однако его разрешается доставлять более одного раза.

Значение QoS, равное 2, приказывает MQTT доставлять сообщения один и только один раз.

Каждое увеличение уровня QoS приводит к дополнительной нагрузке на процессор и сеть. Выбор QoS может повлиять на общие возможности масштабирования вашего решения по обмену сообщениями, а также создаёт дополнительную нагрузку на клиент, связанную с хранением недоставленных сообщений. Следовательно, нужно правильно выбрать соответствующий уровень QoS для каждого опубликованного сообщения. Как правило, следует использовать более низкие значения QoS, если только не требуется более жёсткая гарантия доставки сообщений. Значение QoS, указанное для сообщения, определяет качество сервиса для публикации между клиентом и брокером. Кроме того, это значение устанавливает максимальный уровень QoS, который брокер использует для доставки этого сообщения своим подписчикам.

Подписчики могут указать максимальное значение QoS для доставки сообщений на основе темы, поэтому сообщение, опубликованное с уровнем QoS 2, может быть и не доставлено подписчикам. Подписчик может запросить пониженный уровень QoS для получаемых им сообщений. Хотя может показаться странным, что публикатор не полностью управляет качеством сервиса своих сообщений, в результате увеличивается гибкость для потребителей сообщений. Когда опубликованное сообщение отправляется подписчику, брокер доставляет публикацию либо с максимальным значением QoS, указанным подписчиком во время процесса подписки, либо со значением QoS опубликованного сообщения, если оно ниже. Например, сообщение, опубликованное с QoS = 2 для подписчика, указавшего QoS = 1 для данной темы, доставляется с QoS = 1. Сообщение с QoS = 0, опубликованное для того же подписчика по этой же теме, отправляется подписчику с QoS = 0.

Boolean. Четвёртый параметр, булев флаг (Boolean flag), определяет, является ли эта публикация задержанной. Задержанная публикация удерживается в брокере как последнее полученное сообщение по данной теме. Задержанные публикации позволяют следующим подписчикам получать самые последние сообщения по какой-либо теме, как только они на неё подпишутся, даже если подключение произойдёт после того, как сообщение будет опубликовано. Эта возможность очень полезна для наполнения данными отображающего информацию приложения сразу после его запуска и последующего обновления этой информации при её изменении. Если значение этого флага - false, сообщение получат только подписчики, в данный момент подписанные на эту тему.

В заключение о протоколе MQTT можно сказать, что это мощный транспортный протокол модели обмена сообщениями publish/subscribe. Он полезнее других аналогичных протоколов в тех ситуациях, когда требуются маленький клиент и невысокая нагрузка на сеть. В данной статье рассматривается процесс создания полнофункционального MQTT-публикатора.

2.2 Взаимодействие между интернет-вещами

Концепция Интернета вещей подразумевает не только сбор данных с удалённых и отслеживаемых объектов, не только управление этими объектами, но и обмен информацией объектов между собой, перераспределение задач, планировка с учётом доступности тех или иных сервисов в зоне охвата объекта.Интернет-вещи должны иметь возможность объединяться в локальные беспроводные сети, решая совместные задачи. Это возможно благодаря свойству самоорганизации беспроводных сенсорных сетей.

Существуют сложные задачи, решаемые интернетом вещей, и требующие больших вычислительных ресурсов. Например, обработка видео в реальном времени. При наличии умеренного потока информации локальная сеть “умных камер” способна сама его обработать, однако при усиленной работе системы, локальная беспроводная сетьможет, использовать вычислительные ресурсы облака.Облачные технологии в Интернете вещей разделяются на две:

облачные вычисления,

туманные вычисления.

Туманные вычислительные ресурсы - это как раз те локальные сенсорные сети, из которых состоит Интернет вещей, узлы которых способны решать общие задачи.Под туманом подразумевается приближение облака к земле, в данном случае туман -- это разновидность облачных сервисов, расположенных не где-то в недоступных высотах, а в окружающей нас среде. Иначе говоря, Fog Computing не альтернатива, а дополнение к Cloud Computing, и могут возникнуть ситуации их совместного действия (например, выполнение аналитического приложения), и в таком случае Cloud окажет услугу Fog.

Fog Computing можно определить как в максимальной степени виртуализированную платформу, поддерживающую три основных типа сервисов, образующих M2M: вычисления, хранение и сеть. Задача Fog Computing заключается в обеспечении взаимодействия миллиардов устройств между собой и с облачными ЦОД.

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

Парадигма Fog Computing отличается от Cloud Computing по целому ряду параметров.

Распределение вычислительной мощности и реальное время. Значительные вычислительные ресурсы могут быть размещены на периферии Сети, причем не должно быть зависимости от координат того места, где находится устройство, и при этом работа в режиме реального времени предполагает низкий уровень задержек при обмене данными, к тому же в Fog Computing может произойти конвергенция двух существовавших долгое время автономно друг от друга систем -- управления бизнесом и технологическими системами.

Географическое распределение компонентов. Модель распределения сервисов в Fog Computing менее централизована, чем для облаков, а отдельные устройства могут быть связаны между собой отоками данных и предоставлять друг другу «тяжелые» сервисы.

Большой объем внешних данных. Устройства, экипированные многочисленными сенсорами, могут в реальном времени генерировать гигантские объемы данных. Сложная топология. Миллионы географически распределенных узлов могут создавать разнообразные и не детерминированные заранее связи.

Мобильность и гетерогенность. Мобильность устройств потребует использования альтернативных протоколов, например LISP.

2.2.1 FogComputingв Интернете вещей

Интернет-вещи могут связываться друг с другом вне зависимости от их территориального расположения. Это означает, что в протоколе прикладного уровня должна быть предусмотрена возможность как межсетевого взаимодействия - когда интернет-вещь из одной локальной сети может связываться с вещью из другой сети, так и локального взаимодействия - связи с одной из ближайших вещей.Такие возможности могут быть реализованы как прозрачно, так и посредством реализации соединения с удалённым узлом.

Рисунок 5. Топология сетис архитектурой publish/subscribe

Протокол MQTTоснован на архитектуре publish/subscribe, которая подразумевает обязательное наличие брокера. Отсутствие брокера означает неработоспособность всей сети. Такая архитектура, казалось бы, не распространяется на FogComputing, т.е. локальные сети должны самостоятельно реализовывать распределённые вычисления без помощи MQTT. MQTTпозволяет организовать связь между любыми двумя устройствами посредством взаимной подписки друг на друга через сервер.Такой подход не укладывается в рамки технологии туманных вычислений. Однако возможность прозрачного взаимодействия интернет-вещей по протоколу MQTT вполне реализуема. Такая возможность позволит реализовать туманные вычисления в полной мере, т.е. с возможностью прибегать к помощи облачных вычислений.

Можно выделить следующие способы организации туманных вычислений с помощью MQTT:

брокер локальной сети,

псевдо-сервер MQTT.

Для реализации туманных вычислений с помощью протокола MQTTнеобходимо решить проблему взаимодействия с сетевым протоколом локальной сети.

2.2.2 Использование протокола IP в локальных сетях

Рассмотрим реализацию обеих способов на примере Интернета вещей, основанном на протоколе MQTT, состоящего из локальных сенсорных сетей под управлением протокола ZigBee.

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

Рисунок 6. Функциональная диаграмма приложения для интернет-вещи

На рисунке 6 показана схема приложения для интернет-вещи, содержащей в себе модуль ZigBee (для локальных соединений с ближайшими вещами) и модуль GPRS (для связи с удалённым сервером). В данной ситуации при разработке такого приложения обращение к вещам, находящимся в локальной сети будет производиться по их внутренним адресам в формате протокола ZigBee, в то время как обращение к внешним вещам, находящимся территориально удалённо, будет производиться по протоколу MQTT. Такой подход усложняет разработку приложений с поддержкой концепции FogComputing.

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

Рисунок 7. Приложение с межсетевым интерфейсом

Проблема совместимости сетевых протоколов в Интернете вещей в настоящий момент решается вполне успешно. Существует множество решений по разработке программных интерфейсов для объединения различных протоколов сенсорных сетей (в т.ч. ZigBee) с другими сетевыми протоколами. Наиболее удачное решение продемонстрировала компания Jennic, разрабатывающая беспроводные микроконтроллеры, использующие стандарт 802.15.4, а также программное обеспечение и операционную систему для них (JenNetи JenOS).

Компания Jennic использует протокол IPна сетевом уровне, поверх 802.15.4. Это позволяет обращаться к узлам сенсорной сети, используя IP-адрес и TCP-порт.

При использовании протокола IP, разработчик сможет использовать один из узлов локальной сети в качестве брокера MQTT, отвязав часть интернет-вещей от Интернета.

Также, модифицировав прикладной уровень клиентской части протокола MQTT, станет возможным реализовать прозрачный обмен данными между локальными узлами по протоколу MQTT.

2.2.3 Брокер локальной сети

Беспроводные сенсорные сети имеют архитектуру, поддерживающую любой вид топологии (звезда, дерево, ячеистая) и предусматривающую наличие координатора - узла сети, организующего сеть и играющего роль в некоторой степени напоминающую брокера в сети MQTT.Однако, связь с ближайшим узлом сенсорной сети возможна и без помощи брокера - напрямую.Координатор играет роль брокера в случае невозможности установить связь с узлом в силу его удалённости. Более простыми “брокерами” сенсорных сетей являются маршрутизаторы, которые также предназначены для ретрансляции сообщений от одного узла к другому. Любое конечное устройство сенсорной сети может быть настроено на предоставление услуги маршрутизации.

Наличие таких улов, как координатор и маршрутизатор упрощают задачу интеграции брокера MQTTв локальную сеть. Имея IP-адресацию в локальной сети, любой узел всегда будет знать адрес координатора и ближайшего маршрутизатора.Таким образом, для внедрения протокола MQTTв локальную беспроводную сеть способом локального брокера необходимо:

использовать протокол IP,

установить программное обеспечение брокераMQTTна маршрутизаторы и координатор локальной сети,

установить клиентское ПОMQTT на конечные узлы сети,

использовать таблицу брокеров.

Рисунок 8. Сеть интернет-вещей с локальными брокерами

На рисунке8 изображена топология Интернета вещей после применения метода локального брокера. Такой метод распространяет технологию MQTT на локальные беспроводные сети. Использование данного метода отразится на клиентском приложении только изменением алгоритма подключения к серверу. Теперь при подключении будет использоваться таблица брокеров, включающая в себя как локальные, так и глобальные брокеры.

К недостаткам такого метода можно отнести:

необходимость подключения вещи к нескольким брокерам (локальному и глобальному),

наличие дополнительного устройства для развёртывания на нём брокера,

отсутствие локальной сети в случае недоступности брокера,

связь двух узлов только посредством третьего узла - брокера (отсутствие ячеистой топологии).

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

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

Рисунок 9. Связь узлов и брокеров с ретрансляцией

модификация клиентского ПО MQTT с целью добавления режима multicast. Данный режим должен предусматривать возможность публикации сообщений сразу на все доступные брокеры и возможность обрабатывать адресованные узлу сообщения от разных брокеров одной функцией. Поскольку уникальность идентификаторов устройств в глобальной сети должна распространяться и на локальные сети, то проблем с повторной доставкой сообщений быть не должно. Сообщение будет обработано только тем узлом, которому оно адресовано. К тому же режим multicast поддерживается практически любыми стандартами беспроводной связи.

Рисунок 10. Связь узлов и брокеров в режиме multicast

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

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

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

К достоинствам метода локального брокера можно отнести:

полная прозрачность взаимодействия между интернет-вещами,

автоматическая маршрутизация,

минимальные изменения пользовательского приложения.

2.2.4 Псевдо-сервер MQTT

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

Под псевдо-сервером подразумевается часть программного обеспечения узла, эмулирующая сервер MQTT.

При таком подходе необходимо знать сетевой адрес устройства, к которому мы хотим подключиться. При этом, на уровне приложения, известен только идентификаторMQTT необходимой вещи, а сетевой адрес скрыт. В такой ситуации проблема может быть разрешена при помощи координатора сенсорной сети. При инициализации сети должна создаваться таблица идентификаторов устройств с соответствующими сетевыми адресами всех вещей, входящих в локальную сеть и сохраняться на координаторе. Любой узел сети при необходимости сможет запросить её у координатора (доступ к координатору есть у каждого узла сети) и выполнить присоединение к псевдо-серверу.

На момент соединения с псевдо-сервером отправитель будет знать точно, что это именно тот узел, которому адресуется информация. Узел 1 будет публиковать информацию на псевдо-сервер, не имея ни одного подписчика, в то время как узел 2 будет принимать её и передавать в приложение.

Такой способ является простейшей надстройкой над протоколом MQTT. Главной задачей при таком подходе является инкапсуляция реализации псевдо-сервера и осуществление прозрачного обмена между вещами с помощью определённого набора функций. Это решается путём создания некоторой библиотеки для Point-to-Pointсоединений, содержащей в себе эмуляцию сервера MQTTи соединения клиента с ним.

Для организации прозрачной связи между территориально-удалёнными вещами при таком подходе необходимо сделать обёртку над APIобщения с сервером MQTTи API соединений Point-to-Pointс целью включения алгоритма поиска вещи в локальной сети и автоматической маршрутизации. Поиск вещи в локальной сети будет производиться без особых проблем благодаря таблице устройств, хранимой на координаторе. В случае присутствия вещи в локальной сети, будет использоваться Point-to-PointAPI. В случае отсутствия вещи, будет произведён запрос к глобальному серверу MQTT.

Недостатки такого подхода включают в себя:

необходимость использования APIдля осуществления прозрачных соединений,

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

необходимость внесения изменений в протокол MQTT, реализацию серверной и клиентской части.

Достоинства метода:

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

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

более рациональная топология.

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

Выводы

Среди различных методов физической организации Интернета вещей предпочтение отдаётся методу централизованного сервера, поскольку такой метод переносит нагрузку обработки запросов пользователей с интернет-вещей на централизованный сервер, тем самым разгружая слабый радио-канал связи интернет-вещей, перенося нагрузку на проводные каналы связи между сервером и пользователями,

предоставляет надёжные средства хранения и обработки информации,

позволяет интернет-вещам взаимодействовать друг с другом и пользоваться облачными вычислениями.

Среди недостатков существующих средств организации метода централизованного сервера можно выделить:

отсутствие общепринятого стандарта организации Интернета вещей и интерфейсов взаимодействия,

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

На практике данный метод используется совместно с протоколомMQTT-наиболее развитое и оптимальное средство в условиях экономии электроэнергии и объёма передаваемых данных. Однако протокол MQTTещё не окончательно развит и имеет основную проблему - отсутствие возможности создавать соединения “точка-точка” между двумя узлами одной локальной сети. Это означает невозможность использования технологии туманных вычислений. Однако у этой проблемы есть ряд решений.

Решения проблемы организации локальных межузловых соединений делятся в зависимости от применения. Существуют разные применения для Интернета вещей. В случае необходимости решать задачи, требующие быстрого и частого обмена между узлами сети, более выгодным будет применение способа псевдо-сервера. Однако такой способ является надстройкой над протоколом и нежелателен MQTT, в силу плохой переносимости в будущем на другие системы интернет-вещей.

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

использовать протокол IP,

установить программное обеспечение брокераMQTTна маршрутизаторы и координатор локальной сети,

установить клиентское ПОMQTT на конечные узлы сети,

использовать таблицу брокеров для автоматического выбора сервера-брокера.

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

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

2.3 WEBвещей

Активное развитие Интернета вещей привело к тому, что всё больше пользователей стали использовать Интернет для доступа к всевозможным “умным вещам”. При этом самым удобным способом доступа является всемирная паутина - WorldWideWEB, пользование которой осуществляется с помощью веб-браузеров, способных загружать веб-страницы и представлять их в виде графического интерфейса для пользователей.

Рост числа Интернет-вещей, доступных для управления с помощью Интернета и веб-браузера, говорит о появлении некоторой среды в WEB'е, объединённой общей функциональной направленностью - управлением интернет-вещами. Такая среда получила название WEBвещей.

WEBвещей можно рассматривать как прикладной (или пользовательский) уровень Интернета вещей, поскольку является лишь интерфейсом между пользователем и интернет-вещами.

На начальных этапах развития WEB'а вещей имелось некоторое множество устройств, которые использовали протокол HTTPдля отправки данных на веб-ресурсы. При этом, находясь в одной среде, все интернет-вещи использовали свой формат представления данных, который мог распознаваться только определённым типом веб-приложений. Таким образом, появилась проблема стандартизации обмена информацией в WEB'е вещей.При решении данной проблемы основной целью является обеспечение возможности интернет-вещам публиковать свои сообщения на любом веб-ресурсе, при том условии, что каждая интернет-вещь также является веб-ресурсом. То есть интернет-вещи должны стать частью всемирной паутины и быть наравне с любыми другими веб-ресурсами.

В рамках решения данной проблемы был использован ряд проектов, разработанных ранее для объединения вещей (в основном домашних бытовых, мобильных устройств и компьютеров) в одну вычислительную сеть, который включает в себя JINI, UPnP, DNLA и прочие.Однако организация поддержки данных технологий в WEB'е вещей довольно проблематична, поскольку требует создания интерфейса между внутрисетевыми протоколами и WEB'ом.