Московский институт электроники и математики Национального

Московский институт электроники и математики Национального

исследовательского университета «Высшая школа экономики»

 

Допущен к защите

Заведующий кафедрой ВСиС

___________ А.В. Вишнеков

«__» ____________ 2013 г.

Скороходов Алексей Дмитриевич

ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ВЗАИМОДЕЙСТВИЯ

В ИНТЕРНЕТЕ ВЕЩЕЙ

 

Направление 23.01.00.68 - Информатика и вычислительная техника

Магистерская программа - Сети ЭВМ и телекоммуникации

 

Магистерская диссертация

Научный руководитель   Рецензент

подпись   подпись

доцент, к.т.н, профессор Л.С. Восков   доцент, к.т.н. Рогов А.А.

 

Москва 2013

Оглавление

Введение. 4

Основная часть. 9

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

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

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

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

2.1.1. Протокол MQTT. 21

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

2.2.1. Fog Computing в Интернете вещей. 28

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

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

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

2.2.5. Выводы.. 39

2.3. WEB вещей. 41

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

2.4.1. Проблемы пользовательского интерфейса интернет-вещей. 52

2.4.2. Конструктор виджетов, как решение проблем Интернета вещей. 53

2.4.2.1. Описание конструктора. 55

2.4.2.2. Используемые технологии. 57

2.4.2.3. Примеры веб-виджетов. 64

2.4.3. Выводы.. 69

Заключение. 72

Используемая литература. 75

Приложения. 77

Приложение 1. Исходный код веб-виджета ламп освещения. 77

Приложение 2. Исходный код веб-виджета для умных весов. 84

Приложение 3. Исходный код веб-виджета умной розетки. 87

Приложение 4. Исходный код веб-виджета метеостанции. 91

Приложение 5. Исходный код веб-виджета электросчётчика. 96

Приложение 6. ZigBee-GSM шлюз. Разработка WiSeNet Lab. 111

Принципиальная схема устройства. 111

Топология печатной платы.. 113

Слои 1 и 2. 113

Слои 3 и 4. 114

 

 

Введение

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

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

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

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

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

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

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

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

 

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Основная часть

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

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

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

Второй способ заключается в использовании устройства-шлюза, позволяющего соединить сенсорную сеть с ближайшей проводной сетью, имеющей выход в Интернет. Такой проводной сетью, как правило, является 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, Sierra Wireless для сетей GSM. Встраиваемые модули выпускаются для конструкторских разработок, для создания автоматизированных систем и аппаратно-программных комплексов на их основе.

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

 

 

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

 

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

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

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

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

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

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

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

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

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

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

 

Протокол 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-публикатора.

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

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

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

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

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

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

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

 

 

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

 

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

 

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

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

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

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

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

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

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

 

 

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

 

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

 

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

WEB вещей

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

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

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

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

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