Федеральное государственное автономное образовательное учреждение высшего профессионального образования

Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
Национальный исследовательский университет «Высшая школа
экономики»
Московский институт электроники и математики Национального
исследовательского университета «Высшая школа экономики»
Допущен к защите
Заведующий кафедрой ВСиС
___________ А.В. Вишнеков
«__» ____________ 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
2
Используемая литература ..................................................................................... 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
3
Введение
В настоящее время активно развивается такое направление в области
информационных технологий, как “Интернет вещей” – совокупность
разнообразных приборов, датчиков, устройств, используемых ранее локально
и автономно, объединённых в сеть посредством любых доступных каналов
связи, использующих различные протоколы взаимодействия между собой и
единственный протокол доступа к глобальной сети. В роли глобальной сети
для интернет-вещей, в настоящий момент используется сеть Интернет.
Общим протоколом является IP.
Переход к Интернету вещей, согласно исследованию Cisco, произошёл
примерно
в
2008-2009
годах.
С
подключённых к глобальной сети
этих
пор
количество
устройств,
Интернет, превысило численность
населения Земли. Число инноваций в этой области непрерывно растёт, что
говорит об активном развитии Интернета вещей.
Следует различать понятия “Интернет вещей” и “интернет-вещь”.
Под интернет-вещью понимается любое устройство, которое:
 имеет доступ к сети Интернет с целью передачи или запроса какихлибо данных,
 имеет конкретный адрес в глобальной сети или идентификатор, по
которому можно осуществить обратную связь с вещью,
 имеет интерфейс для взаимодействия с пользователем.
Интернет-вещи имеют единый протокол взаимодействия, согласно
которому любой узел сети равноправен в предоставлении своих сервисов.
Каждый узел сети интернет-вещей предоставляет свой сервис, оказывая
некую услугу поставки данных. В то же время узел такой сети может
принимать команды от любого другого узла. Это означает, что все интернет4
вещи могут взаимодействовать друг с другом и решать совместные
вычислительные задачи.
Рисунок 1. Функциональная схема Интернета вещей
Интернет-вещи могут образовывать локальные сети, объединённые
какой-либо одной зоной обслуживания или функцией. Например, сеть
умного дома, состоящая из различных датчиков, может иметь доступ в
Интернет и иметь возможность управления посредством веб-интерфейса. В
то же время несколько “умных сетей” могут быть объединены в одну
взаимосвязанную сеть мониторинга и управления системой пожаротушения
города, а городские сети могут быть объединены глобальной сетью Интернет
для общего доступа к информации об уровне пожарной безопасности в
любом городе страны. Этот пример представляет собой частный случай
территориально-распределённых сетей, развитию которых поспособствовала
5
активная инновационная деятельность в области беспроводных сенсорных
сетей за последнее десятилетие.
Беспроводные сенсорные сети – одно из активных направлений в
области систем мониторинга – развивалось от локальных сенсорных сетей
до территориально-распределённых, связанных с глобальными сетями
Internetи GSM. В терминологии беспроводных сенсорных сетей часто
встречается такое понятие, как “умная вещь”. С появлением Интернета
вещей все умные вещи, имеющие доступ к сети Интернет, называют
интернет-вещами.
Таким образом, Интернет вещей стал приобретать популярность и
актуальность после появления территориально-распределённых сенсорных
сетей и является решением задачи интеграции сенсорных сетей в
повседневную жизнь. В настоящий момент эта технология находится на
стадии ранней реализации, активных исследований и разработок.
На пути перехода к воплощению идеи интернета вещей стояла
проблема, связанная с протоколом IPv4, ресурс свободных сетевых адресов
которого
уже
себя
практически
исчерпал.
Однако,
подготовка
к
повсеместному внедрению протокола IPv6 позволяет решить эту проблему и
приближает идею Интернета вещей к реальности.
Ещё одним шагом на пути к идее Интернета вещей была технология
M2M (Machine to Machine), совершенство и распространение которой
позволило использовать её в любом мобильном устройстве, в том числе и
узлах сенсорных сетей. Считается, что именно эта технология породила
термин “Интернет вещей”, подразумевая под ним некую обособленную
вычислительную
среду,
состоящую
из
устройств,
самостоятельно
взаимодействующих друг с другом и предоставляющих пользователю
результаты своей совместной деятельности.
6
Интернет вещей в будущем может иметь огромное количество
устройств. По прогнозам аналитиков, к 2020 году общее количество
устройств, подключенных к Сети, составит от 12 до 50 миллиардов единиц.
Поэтому в настоящее время является актуальным вопрос оптимальной
организации Интернета вещей с учётом требований к быстродействию сети в
целом, размеру используемых данных для хранения и энергосбережению
отдельных узлов сети.
Одним из вопросов организации Интернета вещей является разработка
методов взаимодействия между:
1. интернет-вещами,
2. пользователями и интернет-вещами,
3. удалённым сервером и интернет-вещами.
В работе дано описание каждого из типов взаимодействия и варианты
их реализации, которые используются в настоящий момент при разработке
систем интернет-вещей или могут быть использованы в будущем.
Каждая интернет-вещь должна иметь интерфейс для связи с
пользователем, который состоит из программной и визуальной части.
Визуальная часть может использовать довольно большой объём памяти для
хранения, что порождает проблему роста нагрузки на ресурсы сети в
результате увеличения размера используемых данных Интернетом. Данная
проблема решается в ходе выполнения основной задачи (достижения цели
работы) путём разработки веб-приложения – конструктора виджетов, которое
позволяет значительно сократить рост потребления ресурсов сети интернетвещами и убрать линейную зависимость нагрузки от числа интернет-вещей в
сети. Представленное решение также упрощает разработку пользовательских
интерфейсов для интернет-вещей и предоставляет пользователю большую
гибкость при взаимодействии с интернет-вещью, что представляет научную
новизну в решении данной проблемы.
7
Целью
существующих
данной
работы
методов
является
взаимодействия
в
проведение
Интернете
исследования
вещей
между
основными его составными, выявление проблем, связанных с ними и поиск
оптимального их решения.
В данной работе даётся обзор методов взаимодействия в Интернете
вещей,
показываются
существующие
и
прогнозируемые
проблемы,
предлагается решение рассматриваемых проблем с целью улучшить качество
предоставляемых Интернетом вещей услуг.
8
Основная часть
1. Способы взаимодействия в Интернете вещей
В
настоящий
момент
можно
выделить
3
основных
способа
взаимодействия с интернет-вещами:
- прямой доступ,
- доступ через шлюз,
- доступ через сервер.
В случае прямого доступа интернет-вещи должны иметь собственный
IP-адрес или сетевой псевдоним, по которому к ним можно обратиться из
любого клиентского приложения. Интерфейс с такими вещами обычно
выполнен в виде web-ресурса с графическим интерфейсом для управления
посредством веб-браузера. Возможно использование специализированного
программного обеспечения.
Недостатки такого способа очевидны:
- необходимость иметь фиксированный адрес в сети, что зависит от
провайдера услуги связи с Интернетом таких вещей. Другим выходом
из ситуации является использование алиаса (сетевого псевдонима IPадреса), что требует постоянного обращения интернет-вещи к
специальному серверу с запросом об обновлении сетевого адреса по
псевдониму.
- лимит подключений к устройству – вызвано низким качеством связи
интернет-вещей, а также их слабыми вычислительными ресурсами.
Такая проблема решается путём включения в состав интернет-вещи
высокопроизводительного оборудования и подключения вещей к
стабильному
источнику
связи
с
Интернетом.
Это
вызывает
необходимость в большем потреблении энергии такой вещью и часто
9
вынуждает делать такие вещи стационарными, питающимися от
постоянных источников электроэнергии.
Доступ к интернет-вещам через шлюз является более рациональным
способом организации взаимодействия и полностью вытесняет метод
прямого доступа в случае необходимости организации связи беспроводных
сенсорных сетей или сети интернет-вещей с глобальной сетью Интернет.
Большинство стандартов беспроводных сенсорных сетей не поддерживают
протокол IP, используя собственные протоколы взаимодействия. Такая
особенность вызывает необходимость наличия устройства для ретрансляции
сообщений из сенсорной сети в сеть Интернет для совместимости
протоколов.
Недостатки такого подхода те же, что и в случае прямого доступа, но
распространяются они на шлюз.
Доступ к интернет-вещам через сервер подразумевает наличие
посредника между интернет-вещами и пользователем. Таким посредником
является сервер, в основные функции которого входит:
- приём
сообщений
от
интернет-вещей
и
передача
их
пользователям,
- хранение принятой информации и её обработка,
- обеспечение пользовательского интерфейса с возможностью
двустороннего обмена между пользователем и интернет-вещью.
Такой способ доступа является наиболее рациональным и часто
используемым, поскольку позволяет перенести нагрузку обработки запросов
пользователей с интернет-вещей на централизованный сервер, тем самым
разгружая слабый радио-канал связи интернет-вещей, перенося нагрузку на
проводные каналы связи между сервером и пользователями.
10
Метод централизованного сервера также предоставляет надёжные
средства хранения и обработки информации, позволяет интернет-вещам
взаимодействовать друг с другом и пользоваться облачными вычислениями.
Данный подход может использовать метод шлюза для соединения локальных
беспроводных сетей с сервером.
1.1. Использование шлюза
В Интернете вещей шлюз используется не только для прямой связи
интернет-вещей с пользователем, но и при использовании централизованного
сервера. Шлюзы служат средством для объединения локальных сетей
интернет-вещей с глобальной сетью и связью с сервером управления или
конечным пользователем. Поскольку локальные сети интернет-вещей
представляют собой в основном беспроводные сенсорные сети, то шлюзы,
используемые
в
Интернете
вещей,
аналогичны
используемым
в
территориально-распределённых сенсорных сетях. Существует несколько
способов организации шлюзов.
Первый способ заключается в использовании компьютеров, которые
имеют точку доступа к глобальной сети Интернет, и каждая из объединяемых
сетей подключена к такому компьютеру. Основными недостатками такого
подхода являются стоимость и громоздкость. Сенсорные сети состоят из
миниатюрных
датчиков
и
должны
работать
автономно,
однако
территориально-распределённая сенсорная сеть при таком подходе теряет
свойство автономности, поскольку теперь она зависит от наличия
электричества и точки доступа в Интернет на компьютере.
Второй способ заключается в использовании устройства-шлюза,
позволяющего соединить сенсорную сеть с ближайшей проводной сетью,
имеющей выход в Интернет. Такой проводной сетью, как правило, является
Ethernet-сеть. Устройство имеет в себе приёмопередатчик, совместимый с
объединяемой сенсорной сетью, порт для подключения к сети Ethernet и
11
микроконтроллер, выполняющий функции преобразования пакетов одной
сети в формат другой. Такой способ отличается меньшей стоимостью, чем
первый и размер такого устройства небольшой, но оно нуждается в
относительно высоком энергопотреблении из-за того, что стандартные
проводные сети не рассчитаны на низкий уровень сигнала и потребления
энергии. Также такое устройство не может гарантировать наличие точки
доступа в ближайшей проводной сети.
Третий способ заключается в использовании устройства-шлюза,
которое является полностью автономным и само предоставляет точку
доступа к сети Интернет. Это возможно при использовании беспроводных
технологий
передачи
данных.
приёмопередатчика, совместимого
Устройство
состоит
с сенсорной сетью и
из
одного
второго
–
совместимого с той или иной глобальной беспроводной сетью, в область
действия которой попадает сенсорная сеть. Такими сетями могут служить
GSM или WiMAX. Использование сети GSM является более экономичным в
плане энергопотребления.
Существуют также шлюзы, предоставляющие доступ сенсорным сетям
к ближайшим сетям Wi-Fi для поиска точки доступа к сети Интернет.
Таким образом, если необходимо организовать полностью автономную
территориально-распределённую сенсорную сеть, то следует использовать
третий способ. Если же сенсорная сеть используется как часть какой-либо
крупной проводной сети, то нет необходимости в её полной автономности и
возможно использование первых двух способов.
12
Рисунок 2. Шлюз в территориально-распределённых сенсорных сетях
Чаще всего в Интернете вещей используется третий способ шлюз, имеющий аппаратно-программные средства для работы в сетях ZigBee
и GSM, а также имеющий возможность использования GPRS/EDGE канала
для доступа в сеть Internet. В силу данной особенности и того, что локальные
сети интернет-вещей обычно основаны на стеке протоколов ZigBee, наиболее
часто используемым устройством является ZigBee-GSM шлюз.
ZigBee-GSM шлюз представляет из себя систему, состоящую из двух
основных частей: узел сети ZigBee и узел сети GSM, соединённых
последовательным интерфейсом UART. В качестве узлов этих сетей могут
выступать
встраиваемые
модули.
Такие
модули
разрабатываются
различными компаниями, такими как Jennic, Digi для сетей ZigBee и Siemens,
Sierra Wireless для сетей GSM. Встраиваемые модули выпускаются для
конструкторских разработок, для создания автоматизированных систем и
аппаратно-программных комплексов на их основе.
13
Ниже представлена упрощённая общая схема ZigBee-GSM шлюза.
VBATT
TXD
Модуль
ZigBee
RXD
CTS
RTS
Модуль
GSM/GPRS
GND
UART
Рисунок 3. Функциональная схема ZigBee-GSM шлюза
В настоящее время шлюзы в сенсорных сетях активно используются для
интеграции и совместной работы различных технологий. За последние 4 года
различными компаниями были разработаны всевозможные варианты шлюзов
для сенсорных сетей, объединяющих в себе все современные беспроводные
технологии, такие как Wi-Fi, WiMAX, GSM/GPRS, Bluetooth, GPS.
Современная тенденция в разработке шлюзов для сенсорных сетей
направлена в первую очередь на использование новейших беспроводных
технологий и интеграцию их в одном устройстве. Однако для интернетвещей сохраняется приоритет в таких критериях, как стоимость и
энергопотребление. Поэтому шлюзы должны им соответствовать и иметь не
слишком сложную и дорогую конструкцию.
Говоря об энергопотреблении приёмопередающих устройств можно
сказать, что операция передачи данных на сервер состоит из следующих
этапов:
14
- накопление информации;
- включение или выход из режима сна GSM/GPRS модуля;
- установка соединения с сервером;
- передача информации;
- переход в спящий режим или выключение.
Был проведён ряд исследований, где установлено, что GSM/GPRS
устройства тратят от нескольких до десятков секунд на установление связи с
сетью, а также, в случае использования TCP/IP стека, на получение IP-адреса
и установление соединения с сервером. Соответственно, если необходимо
использовать спящий режим, то время сна и накопления информации нужно
взять сравнительно больше, чем время соединения устройства с сервером.
На кафедре вычислительных систем и сетей в лаборатории WiSeNet
Lab был разработан ZigBee-GSM шлюз, максимально удовлетворяющий
критериям стоимости и энергопотребления. Это было достигнуто путём
подбора компонентов для разрабатываемого устройства, в том числе и
основных модулей, выбирая их по данным критериям. Была также
разработана математическая модель энергопотребления ZigBee-GSM шлюза,
позволяющая сконфигурировать его в соответствии с любыми требованиями
к потреблению энергии.
1.2. Централизованный сервер как метод взаимодействия
Большинство интернет-вещей представляют собой самостоятельные
устройства, передающие некоторую информацию в базу данных для
последующей обработки и передачи конечным пользователям. Для сбора,
хранения,
обработки,
упрощения
поиска,
контроля
и
визуализации
информации используется централизованный сервер управления интернетвещами, который включает в себя:
15
- модуль обработки информации,
- базу данных для хранения собираемой информации,
- интерфейс
взаимодействия
с
интернет-вещами
(некоторый
протокол, поддерживаемый всеми вещами),
- систему контроля пользовательского доступа к вещам, управления
их иерархией, параметрами и функционалом.
Последний пункт может быть перенесён на отдельный сервер и
вынесен в обособленную систему управления, отделяя друг от друга базу
собираемых данных и базу данных управления вещами.
Модуль обработки информации может производить распаковку сжатой
для ускорения транспортировки информации, произведения арифметических
и логических вычислений, классификацию и преобразование принятой
информации к понятному формату восприятия.
Для хранения информации с подведения некоторой статистики,
необходимой для мониторинга объектов, а также предоставления актуальной
опубликованной информации всем пользователям независимо от их времени
подключения используется база данных.
Управление интернет-вещами производится также через сервер.
Пользователь отправляет команду на сервер управления, а он, в свою
очередь, транслирует её адресату. Набор команд управления должен быть
минимальным и общим для всех интернет-вещей для обеспечения полного
отделения управления от данных. Это важное требование к интернет-вещам,
поскольку позволяет значительно упростить обмен информацией между
пользователями и вещами, а также сделать шаг на пути к стандартизации
методов взаимодействия в Интернете вещей и созданию общего центра
управления.
16
Отделение управляющей информации от данных подразумевает
выделение минимального набора команд и сущностей, над которыми эти
команды могут быть выполнены. Например, для выключения лампочки,
включения тостера или переключение режима съёмки видеокамеры можно
выполнять одну и ту же команду – запись. Данными в таком случае будут
являться состояния устройств. Для получения информации необходимо
выполнить чтение текущего состояния устройства или отдельной его
составной части.
При использовании централизованного сервера управления, структуру
сети (топологию) Интернета вещей можно рассматривать с двух сторон:
реальная (физическая топология) и топология с учётом непрямых связей
(логическая).
Физическая Топология Интернета вещей – звезда – все интернет-вещи
или группы вещей соединены с сервером по отдельности.
Логическая же топология может быть абсолютно любой. Любые 2
вещи могут быть соединены как местным беспроводным каналом, так и
внешним – через сервер управления, обеспечивая непрямую связь.
Предоставление услуг одной вещью другой может быть как абсолютно
прозрачным (вне зависимости от территориального расположения вещи), так
и с разделением на 2 протокола для локальной сети и связи с удалённой
вещью.
17
Рисунок 4. Физическая Топология Интернета вещей с использованием
централизованного сервера
Беспроводная
локальная
сеть
интернет-вещей
может
быть
организована средствами протоколов ZigBee, Wi-Fi, Bluetooth и других
протоколов беспроводной связи малой зоны действия, а связь с сервером
управления может быть установлена посредством глобальной сети Интернет.
При этом могут использоваться технологии GPRS, WiMAX, направленная
радиопередача, проводные каналы связи.
18
ZigBee – наиболее часто используемый протокол для беспроводных
сенсорных сетей. ZigBee — это по сути не отдельный протокол, а
спецификация сетевых протоколов верхнего уровня (уровня приложений и
сетевого уровня), использующих сервисы нижних уровней — уровня
управления доступом к среде и физического уровня, регламентированных
стандартом IEEE 802.15.4. ZigBee и IEEE 802.15.4 описывают беспроводные
персональные
вычислительные
сети
(WPAN).
Спецификация
ZigBee
ориентирована на приложения, требующие гарантированной безопасной
передачи данных при относительно небольших скоростях и возможности
длительной работы сетевых устройств от автономных источников питания
(батарей).
Основная особенность технологии ZigBee заключается в том, что она
при малом энергопотреблении поддерживает не только простые топологии
сети («точка-точка», «дерево» и «звезда»), но и самоорганизующуюся и
самовосстанавливающуюся ячеистую (mesh) топологию с ретрансляцией и
маршрутизацией сообщений. Кроме того, спецификация ZigBee содержит
возможность
выбора
алгоритма
маршрутизации,
в
зависимости
от
требований приложения и состояния сети, механизм стандартизации
приложений — профили приложений, библиотека стандартных кластеров,
конечные точки, привязки, гибкий механизм безопасности, а также
обеспечивает простоту развертывания, обслуживания и модернизации.
2. Виды взаимодействия в Интернете вещей
Интернет вещей представляет собой вычислительную сеть, имеющую
- основные узлы – интернет-вещи,
- серверы управления интернет-вещами,
- пользовательские узлы – мобильные и персональные вычислительные
устройства.
19
Таким образом, можно выделить 3 основных вида взаимодействий в
Интернете вещей:
1. взаимодействие между интернет-вещами,
2. взаимодействие между пользователями и интернет-вещами,
3. взаимодействие между удалённым сервером и интернет-вещами.
2.1. Взаимодействие между удалённым сервером и интернет-вещами
Все интернет-вещи в большинстве своём используют радиочастотный
канал данных, зачастую с весьма ограниченной пропускной способностью,
несмотря на огромный объём передаваемых данных в некоторых случаях. В
то
же
время
интернет-вещь
имеет
и
жёсткие
ограничения
по
вычислительным ресурсам. Это создаёт следующие ограничения для
протокола обмена между вещью и концентратором данных (концентратор
данных – сервер, шлюз или любое другое устройство, принимающее и
маршрутизирующее или фиксирующее данные от интернет-вещи):
- минимизация трафика,
- максимальное исключение ошибок передачи данных и трансляции
команд,
- поддержка функции делегирования задачи другой вычислительной
единице.
Протоколом сетевого уровня для существующих в настоящий момент
интернет-вещей является IP, над которым возможно применение протоколов
транспортного
уровня со
специальными
модификациями. В разных
источниках рассматривается также вопрос о замене протокола IP с целью
улучшить алгоритм маршрутизации для обеспечения мобильности интернетвещей (например, протоколы Locator/ID Separation Protocol (LISP) и Six/One).
20
Протокол 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. Для
создания
21
подключения
к брокеру
необходимо выполнить несколько шагов. Создаётся объект свойств MQTT,
который затем передаётся фабрике создания клиента. Этот объект свойств
предоставляет конфигурацию созданному экземпляру клиента. Одно из этих
свойств - булев флаг (Boolean flag), указывающий, является ли клиентское
приложение "клиентом без сохранения сеанса". Если значение флага - true,
при каждом подключении клиент не будет знать о предыдущем соединении с
брокером (например, о любых ранее сделанных подписках или об
ожидающих доставки сообщениях). Если значение флага - false, состояние
клиента при различных подключениях к брокеру остаётся прежним;
например, клиентскому приложению не потребуется повторная подписка при
каждом последующем переподключении. Кроме того, в этом случае клиент и
брокер пытаются возобновить любой выполняющийся в данный момент
обмен сообщениями (в зависимости от определённого для сообщений
качества сервиса), прерванный при разрыве соединения. Для использования
"клиента с сохранением сеанса" необходимо обеспечить реализацию
интерфейса MqttPersistence. Включение реализации этого интерфейса
обозначает для фабрики создания клиента, что клиентскому приложению
требуется персистентная (надёжная) доставка сообщений. После настройки
свойств мы получаем экземпляр MQTT-клиента из фабрики MQTT-клиента.
Для создания экземпляра MQTT-клиента требуется несколько параметров, в
том числе уникальный идентификатор клиента (client ID), IP-адрес и порт
брокера, а также дополнительный объект MqttProperties, описанный ранее.
Идентификатор клиента идентифицирует каждого клиента брокеру. В
первую очередь это гарантирует надёжную передачу сообщений и
поддерживает состояние подписки при множественных подключениях и
отключениях клиента. Важно заметить, что идентификатор каждого клиента,
подключающегося в брокеру, должен быть отличен от других. Если два
клиента попытаются выполнить подключение к брокеру с помощью одного и
того же идентификатора клиента, предпочтение будет отдано последнему
22
соединению, а более раннее будет принудительно отключено. Это сделано
для того, чтобы обеспечить повторное подключение клиента к предыдущему
соединению, которое не было полностью очищено. Идентификатор клиента
может иметь длину до 23 символов.
После успешного подключения MQTT можно публиковать сообщения.
Приложения
Сигнатура
выполняют
метода
для
публикацию
публикации
через
объект
сообщения
-
int
MQTT-клиента.
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, чтобы убедиться в том, что сообщение доставлено.
23
Этот уровень иногда называют "выстрелил и забыл", так как сообщение
отправляется адресату без проверки получения.
При QoS, равном 1, доставка сообщения брокеру проверяется; однако
его разрешается доставлять более одного раза.
Значение QoS, равное 2, приказывает MQTT доставлять сообщения
один и только один раз.
Каждое увеличение уровня QoS приводит к дополнительной нагрузке
на процессор и сеть. Выбор QoS может повлиять на общие возможности
масштабирования вашего решения по обмену сообщениями, а также создаёт
дополнительную
нагрузку
на
клиент,
связанную
с
хранением
недоставленных сообщений. Следовательно, нужно правильно выбрать
соответствующий уровень QoS для каждого опубликованного сообщения.
Как правило, следует использовать более низкие значения QoS, если только
не требуется более жёсткая гарантия доставки сообщений. Значение QoS,
указанное для сообщения, определяет качество сервиса для публикации
между клиентом и брокером. Кроме того, это значение устанавливает
максимальный уровень QoS, который брокер использует для доставки этого
сообщения своим подписчикам.
Подписчики могут указать максимальное значение QoS для доставки
сообщений на основе темы, поэтому сообщение, опубликованное с уровнем
QoS 2, может быть и не доставлено подписчикам. Подписчик может
запросить пониженный уровень QoS для получаемых им сообщений. Хотя
может показаться странным, что публикатор не полностью управляет
качеством сервиса своих сообщений, в результате увеличивается гибкость
для
потребителей
отправляется
сообщений.
подписчику,
Когда
брокер
24
опубликованное
доставляет
публикацию
сообщение
либо
с
максимальным значением QoS, указанным подписчиком во время процесса
подписки, либо со значением QoS опубликованного сообщения, если оно
ниже. Например, сообщение, опубликованное с QoS = 2 для подписчика,
указавшего QoS = 1 для данной темы, доставляется с QoS = 1. Сообщение с
QoS = 0, опубликованное для того же подписчика по этой же теме,
отправляется подписчику с QoS = 0.

Boolean. Четвёртый параметр, булев флаг (Boolean
flag), определяет, является ли эта публикация задержанной.
Задержанная публикация удерживается в брокере как последнее
полученное
сообщение
по
данной
теме.
Задержанные
публикации позволяют следующим подписчикам получать самые
последние сообщения по какой-либо теме, как только они на неё
подпишутся, даже если подключение произойдёт после того, как
сообщение будет опубликовано. Эта возможность очень полезна
для
наполнения
данными
отображающего
информацию
приложения сразу после его запуска и последующего обновления
этой информации при её изменении. Если значение этого флага false, сообщение получат только подписчики, в данный момент
подписанные на эту тему.
В заключение о протоколе MQTT можно сказать, что это мощный
транспортный протокол модели обмена сообщениями publish/subscribe. Он
полезнее других аналогичных протоколов в тех ситуациях, когда требуются
маленький клиент и невысокая нагрузка на сеть. В данной статье
рассматривается
процесс
создания
публикатора.
25
полнофункционального
MQTT-
2.2. Взаимодействие между интернет-вещами
Концепция Интернета вещей подразумевает не только сбор данных с
удалённых и отслеживаемых объектов, не только управление этими
объектами,
но
и
обмен
информацией
объектов
между
собой,
перераспределение задач, планировка с учётом доступности тех или иных
сервисов в зоне охвата объекта. Интернет-вещи должны иметь возможность
объединяться в локальные беспроводные сети, решая совместные задачи. Это
возможно благодаря свойству самоорганизации беспроводных сенсорных
сетей.
Существуют сложные задачи, решаемые интернетом вещей, и
требующие больших вычислительных ресурсов. Например, обработка видео
в реальном времени. При наличии умеренного потока информации локальная
сеть “умных камер” способна сама его обработать, однако при усиленной
работе
системы,
локальная
беспроводная
сеть
может,
использовать
вычислительные ресурсы облака. Облачные технологии в Интернете вещей
разделяются на две:
- облачные вычисления,
- туманные вычисления.
Туманные вычислительные ресурсы – это как раз те локальные
сенсорные сети, из которых состоит Интернет вещей, узлы которых
способны решать общие задачи. Под туманом подразумевается приближение
облака к земле, в данном случае туман — это разновидность облачных
сервисов, расположенных не где-то в недоступных высотах, а в окружающей
нас среде. Иначе говоря, Fog Computing не альтернатива, а дополнение к
Cloud Computing, и могут возникнуть ситуации их совместного действия
(например, выполнение аналитического приложения), и в таком случае Cloud
окажет услугу Fog.
26
Fog Computing можно определить как в максимальной степени
виртуализированную платформу, поддерживающую три основных типа
сервисов, образующих M2M: вычисления, хранение и сеть. Задача Fog
Computing
заключается
в
обеспечении
взаимодействия
миллиардов
устройств между собой и с облачными ЦОД.
Туман можно представить в виде трехуровневой модели. Верхний
уровень занимают тысячи облачных ЦОД, предоставляющих ресурсы,
необходимые
для
выполнения
серьезных,
например
аналитических,
приложений. Уровнем ниже располагаются десятки тысяч распределенных
управляющих ЦОД, в которых содержится «интеллект» Fog Computing, а на
нижнем уровне находятся миллионы отдельных устройств.
Парадигма Fog Computing отличается от Cloud Computing по целому
ряду параметров.
 Распределение вычислительной мощности и реальное время.
Значительные вычислительные ресурсы могут быть размещены
на периферии Сети, причем не должно быть зависимости от
координат того места, где находится устройство, и при этом
работа в режиме реального времени предполагает низкий
уровень задержек при обмене данными, к тому же в Fog
Computing может произойти конвергенция двух существовавших
долгое время автономно друг от друга систем — управления
бизнесом и технологическими системами.
 Географическое
распределение
компонентов.
Модель
распределения сервисов в Fog Computing менее централизована,
чем для облаков, а отдельные устройства могут быть связаны
между собой отоками данных и предоставлять друг другу
«тяжелые» сервисы.
27
 Большой объем внешних данных. Устройства, экипированные
многочисленными
сенсорами,
могут
в
реальном
времени
генерировать гигантские объемы данных. Сложная топология.
Миллионы географически распределенных узлов могут создавать
разнообразные и не детерминированные заранее связи.
 Мобильность
и
гетерогенность.
Мобильность
устройств
потребует использования альтернативных протоколов, например
LISP.
2.2.1. Fog Computing в Интернете вещей
Интернет-вещи могут связываться друг с другом вне зависимости от их
территориального расположения. Это означает, что в протоколе прикладного
уровня
должна
быть
предусмотрена
возможность
как
межсетевого
взаимодействия – когда интернет-вещь из одной локальной сети может
связываться с вещью из другой сети, так и локального взаимодействия –
связи с одной из ближайших вещей. Такие возможности могут быть
реализованы как прозрачно, так и посредством реализации соединения с
удалённым узлом.
28
Рисунок 5. Топология сети с архитектурой publish/subscribe
Протокол MQTT основан на архитектуре publish/subscribe, которая
подразумевает обязательное наличие брокера. Отсутствие брокера означает
неработоспособность всей сети. Такая архитектура, казалось бы, не
распространяется
на
Fog
Computing,
т.е.
локальные
сети
должны
самостоятельно реализовывать распределённые вычисления без помощи
MQTT. MQTT позволяет организовать связь между любыми двумя
устройствами посредством взаимной подписки друг на друга через сервер.
Такой подход не укладывается в рамки технологии туманных вычислений.
Однако возможность прозрачного взаимодействия интернет-вещей по
протоколу
MQTT
вполне
реализуема.
Такая
возможность
позволит
реализовать туманные вычисления в полной мере, т.е. с возможностью
прибегать к помощи облачных вычислений.
Можно
выделить
следующие
вычислений с помощью MQTT:
29
способы
организации
туманных
- брокер локальной сети,
- псевдо-сервер MQTT.
Для реализации туманных вычислений с помощью протокола MQTT
необходимо решить проблему взаимодействия с сетевым протоколом
локальной сети.
2.2.2. Использование протокола IP в локальных сетях
Рассмотрим реализацию обеих способов на примере Интернета вещей,
основанном на протоколе MQTT, состоящего из локальных сенсорных сетей
под управлением протокола ZigBee.
Современные
интернет-вещи
имеют
программное
обеспечение,
управляющее двумя средствами связи – локальным беспроводным каналом и
каналом для связи с глобальной сетью.
Рисунок 6. Функциональная диаграмма приложения для интернет-вещи
На рисунке 6 показана схема приложения для интернет-вещи,
содержащей в себе модуль ZigBee (для локальных соединений с
30
ближайшими вещами) и модуль GPRS (для связи с удалённым сервером). В
данной ситуации при разработке такого приложения обращение к вещам,
находящимся в локальной сети будет производиться по их внутренним
адресам в формате протокола ZigBee, в то время как обращение к внешним
вещам, находящимся территориально удалённо, будет производиться по
протоколу MQTT. Такой подход усложняет разработку приложений с
поддержкой концепции Fog Computing.
Для
разработки
приложений
интернет-вещей,
поддерживающих
туманные вычисления, необходимо ввести ещё одно звено в цепочку
обращений от приложений к радио-модулям устройства. Такое звено будет
является межсетевым интерфейсом, с помощью которого программист
сможет обращаться к интернет-вещам по тем же идентификаторам, которые
используются в глобальной сети при этом не задумываясь о том где
находится вещь.
Рисунок 7. Приложение с межсетевым интерфейсом
31
Проблема совместимости сетевых протоколов в Интернете вещей в
настоящий момент решается вполне успешно. Существует множество
решений по разработке программных интерфейсов для объединения
различных протоколов сенсорных сетей (в т.ч. ZigBee) с другими сетевыми
протоколами. Наиболее удачное решение продемонстрировала компания
Jennic, разрабатывающая беспроводные микроконтроллеры, использующие
стандарт 802.15.4, а также программное обеспечение и операционную
систему для них (JenNet и JenOS).
Компания Jennic использует протокол IPна сетевом уровне, поверх
802.15.4. Это позволяет обращаться к узлам сенсорной сети, используя IPадрес и TCP-порт.
При использовании протокола IP, разработчик сможет использовать
один из узлов локальной сети в качестве брокера MQTT, отвязав часть
интернет-вещей от Интернета.
Также,
модифицировав
прикладной
уровень
клиентской
части
протокола MQTT, станет возможным реализовать прозрачный обмен
данными между локальными узлами по протоколу MQTT.
2.2.3. Брокер локальной сети
Беспроводные сенсорные сети имеют архитектуру, поддерживающую
любой вид топологии (звезда, дерево, ячеистая) и предусматривающую
наличие координатора – узла сети, организующего сеть и играющего роль в
некоторой степени напоминающую брокера в сети MQTT.Однако, связь с
ближайшим узлом сенсорной сети возможна и без помощи брокера –
напрямую. Координатор играет роль брокера в случае невозможности
установить связь с узлом в силу его удалённости. Более простыми
32
“брокерами” сенсорных сетей являются маршрутизаторы, которые также
предназначены для ретрансляции сообщений от одного узла к другому.
Любое конечное устройство сенсорной сети может быть настроено на
предоставление услуги маршрутизации.
Наличие таких улов, как координатор и маршрутизатор упрощают
задачу интеграции брокера MQTTв локальную сеть. Имея IP-адресацию в
локальной сети, любой узел всегда будет знать адрес координатора и
ближайшего маршрутизатора. Таким образом, для внедрения протокола
MQTTв локальную беспроводную сеть способом локального брокера
необходимо:
- использовать протокол IP,
- установить
программное
обеспечение
брокера
MQTT
маршрутизаторы и координатор локальной сети,
- установить клиентское ПО MQTT на конечные узлы сети,
- использовать таблицу брокеров.
Рисунок 8. Сеть интернет-вещей с локальными брокерами
33
на
На рисунке 8 изображена топология Интернета вещей после
применения метода локального брокера. Такой метод распространяет
технологию MQTT на локальные беспроводные сети. Использование данного
метода отразится на клиентском приложении только изменением алгоритма
подключения к серверу. Теперь при подключении будет использоваться
таблица брокеров, включающая в себя как локальные, так и глобальные
брокеры.
К недостаткам такого метода можно отнести:
- необходимость подключения вещи к нескольким брокерам
(локальному и глобальному),
- наличие дополнительного устройства для развёртывания на нём
брокера,
- отсутствие локальной сети в случае недоступности брокера,
- связь двух узлов только посредством третьего узла – брокера
(отсутствие ячеистой топологии).
Необходимость подключения сразу к двум брокерам приведёт к тому,
что одни и те же данные придётся публиковать дважды. Выходы из этой
ситуации следующие:
- доработка
программного
обеспечения
локального
брокера
с
добавлением функции ретрансляции сообщений от вещей на
глобальный брокер. В таком случае, если локальный брокер
включен, конечные устройства будут использовать его в первую
очередь (приоритет локального брокера всегда максимален), а
локальный брокер должен иметь возможность устанавливать
множество
соединений
с
34
глобальным
брокером
и
публиковать/принимать сообщения от имени соответствующих
вещей.
Рисунок 9. Связь узлов и брокеров с ретрансляцией
- модификация клиентского ПО MQTT с целью добавления режима
multicast. Данный режим должен предусматривать возможность
публикации сообщений сразу на все доступные брокеры и
возможность обрабатывать адресованные узлу сообщения от разных
брокеров
одной
идентификаторов
функцией.
устройств
в
Поскольку
глобальной
уникальность
сети
должна
распространяться и на локальные сети, то проблем с повторной
доставкой
сообщений
быть
не
должно.
Сообщение
будет
обработано только тем узлом, которому оно адресовано. К тому же
режим multicast поддерживается практически любыми стандартами
беспроводной связи.
35
Рисунок 10. Связь узлов и брокеров в режиме multicast
Проблема необходимости дополнительного устройства актуальна
только в тех случаях, когда необходимо использование более одного
локального брокера. В случае же, когда можно обойтись всего одним
локальным брокером такая проблема решается установкой брокерного
программного обеспечения на устройство координатора. Шлюз связи с
глобальной сетью также может служить платформой как для координатора,
так и для локального брокера.
В случае недоступности брокера или выхода его из строя, сенсорная
сеть самовосстановится, однако сеть вещей распадётся, если не будет
запасного брокера. Такая проблема решается внедрением брокеров на
доступные маршрутизаторы сети, или на все узлы сети. Во время выхода из
строя основного локального брокера, один из узлов, по возможности,
трансформируется в брокер, загрузив сохранённую в нём программу сервераброкера. Некоторые беспроводные сенсорные сети имеют подобный
механизм восстановления – когда вышедший из строя координатор может
быть заменён одним из маршрутизаторов сети.
Полное переключение узла в режим брокера также может быть
заменено на дополнительное включение программы сервера-брокера. Т.е.
узел будет продолжать функционировать в прежнем режиме, но параллельно
36
с приложением конечного устройства на узле будет запущен локальный
брокер.
К достоинствам метода локального брокера можно отнести:
- полная прозрачность взаимодействия между интернет-вещами,
- автоматическая маршрутизация,
- минимальные изменения пользовательского приложения.
2.2.4. Псевдо-сервер MQTT
Недостатки метода локального брокера позволяет убрать ещё один
способ организации туманных вычислений на основе протокола MQTT –
реализовать эмуляцию сервера для каждого узла локальной сети. При этом
нет необходимости использовать весь функционал сервера на клиентском
узле. Важно лишь обеспечить связь между двумя узлами.
Под
псевдо-сервером
подразумевается
часть
программного
обеспечения узла, эмулирующая сервер MQTT.
При таком подходе необходимо знать сетевой адрес устройства, к
которому мы хотим подключиться. При этом, на уровне приложения,
известен только идентификатор MQTT необходимой вещи, а сетевой адрес
скрыт. В такой ситуации проблема может быть разрешена при помощи
координатора сенсорной сети. При инициализации сети должна создаваться
таблица
идентификаторов
устройств
с
соответствующими
сетевыми
адресами всех вещей, входящих в локальную сеть и сохраняться на
координаторе. Любой узел сети при необходимости сможет запросить её у
координатора (доступ к координатору есть у каждого узла сети) и выполнить
присоединение к псевдо-серверу.
На момент соединения с псевдо-сервером отправитель будет знать
точно, что это именно тот узел, которому адресуется информация. Узел 1
37
будет публиковать информацию на псевдо-сервер, не имея ни одного
подписчика, в то время как узел 2 будет принимать её и передавать в
приложение.
Такой способ является простейшей надстройкой над протоколом
MQTT. Главной задачей при таком подходе является инкапсуляция
реализации псевдо-сервера и осуществление прозрачного обмена между
вещами с помощью определённого набора функций. Это решается путём
создания некоторой библиотеки для Point-to-Point соединений, содержащей в
себе эмуляцию сервера MQTT и соединения клиента с ним.
Для организации прозрачной связи между территориально-удалёнными
вещами при таком подходе необходимо сделать обёртку над API общения с
сервером MQTT и API соединений Point-to-Point с целью включения
алгоритма поиска вещи в локальной сети и автоматической маршрутизации.
Поиск вещи в локальной сети будет производиться без особых проблем
благодаря таблице устройств, хранимой на координаторе. В случае
присутствия вещи в локальной сети, будет использоваться Point-to-Point API.
В случае отсутствия вещи, будет произведён запрос к глобальному серверу
MQTT.
Недостатки такого подхода включают в себя:
- необходимость использования API для осуществления прозрачных
соединений,
- серверный функционал узлов сети, следствием использования
которого является увеличение энергопотребления сети,
- необходимость внесения изменений в протокол MQTT, реализацию
серверной и клиентской части.
Достоинства метода:
38
- нет необходимости использовать отдельное устройство для
развёртывания брокера,
- взаимодействие может быть осуществлено между любыми двумя
близлежащими устройствами без участия посредников,
- более рациональная топология.
Способ псевдо-сервера, несмотря на достоинства, является надстройкой над
протоколом MQTT, альтернативой чему может служить доработка протокола
с целью поддержки туманных вычислений. Изменение протокола возможно с
поддержкой обратной совместимости, однако встраивание такого решения в
существующие системы будет непростой задачей.
2.2.5. Выводы
Среди различных методов физической организации Интернета вещей
предпочтение отдаётся методу централизованного сервера, поскольку такой
метод
- переносит
нагрузку
интернет-вещей
на
обработки
запросов
централизованный
пользователей
сервер,
с
тем самым
разгружая слабый радио-канал связи интернет-вещей, перенося
нагрузку на проводные каналы связи между сервером и
пользователями,
- предоставляет
надёжные
средства
хранения
и
обработки
информации,
- позволяет интернет-вещам взаимодействовать друг с другом и
пользоваться облачными вычислениями.
Среди недостатков существующих средств организации метода
централизованного сервера можно выделить:
39
- отсутствие общепринятого стандарта организации Интернета вещей
и интерфейсов взаимодействия,
- отсутствие универсального протокола, поддерживающего туманные
вычисления и обеспечивающего прозрачную, территориально
независимую связь между интернет-вещами.
На практике данный метод используется совместно с протоколом
MQTT – наиболее развитое и оптимальное средство в условиях экономии
электроэнергии и объёма передаваемых данных. Однако протокол MQTT ещё
не окончательно развит и имеет основную проблему -
отсутствие
возможности создавать соединения “точка-точка” между двумя узлами одной
локальной сети. Это означает невозможность использования технологии
туманных вычислений. Однако у этой проблемы есть ряд решений.
Решения проблемы организации локальных межузловых соединений
делятся в зависимости от применения. Существуют разные применения для
Интернета вещей. В случае необходимости решать задачи, требующие
быстрого и частого обмена между узлами сети, более выгодным будет
применение способа псевдо-сервера. Однако такой способ является
надстройкой над протоколом и нежелателен MQTT, в силу плохой
переносимости в будущем на другие системы интернет-вещей.
Более надёжным и хорошо применимым к любым существующим
системам,
основанным
на
протоколе
способом
MQTT,
является
использование локального брокера. Такой метод изменяет лишь структуру
сети,
добавляя
в
пользовательское
приложение
минимум
нового
функционала. Для использования такого метода в локальных сетях,
необходимо:
- использовать протокол IP,
- установить
программное
обеспечение
брокера
маршрутизаторы и координатор локальной сети,
40
MQTT
на
- установить клиентское ПО MQTT на конечные узлы сети,
- использовать таблицу брокеров для автоматического выбора
сервера-брокера.
Рост числа интернет-вещей увеличивает нагрузку на сервер-брокер.
Такая проблема решается увеличением числа серверов. Интернет-вещи при
этом используют сервер, задержка сигнала до которого минимальна, т.е.
ближайший сервер. При этом потребность интернет-вещи в ресурсах сервера
может быть точно вычислена, а передаваемые данные минимальны.
Интернет-вещь по сравнению с человеком, использует и передаёт на порядок
меньше данных. Всё это говорит о неактуальности проблемы нагрузки на
сервер-брокер.
В
процессе
расширения
Интернета
вещей
внутрисетевое
взаимодействие будет обеспечивать достаточную производительность при
минимальных нагрузках на сеть. Это означает, что необходимо провести
исследование
методов
взаимодействия
между
интернет-вещами
и
пользователем и оценить их нагрузку на сетевые ресурсы.
2.3. WEB вещей
Активное развитие Интернета вещей привело к тому, что всё больше
пользователей стали использовать Интернет для доступа к всевозможным
“умным вещам”. При этом самым удобным способом доступа является
всемирная паутина – World Wide WEB, пользование которой осуществляется
с
помощью
веб-браузеров,
способных
загружать
веб-страницы
и
представлять их в виде графического интерфейса для пользователей.
Рост числа Интернет-вещей, доступных для управления с помощью
Интернета и веб-браузера, говорит о появлении некоторой среды в WEB’е,
41
объединённой общей функциональной направленностью – управлением
интернет-вещами. Такая среда получила название WEB вещей.
WEB
вещей
можно
рассматривать
как
прикладной
(или
пользовательский) уровень Интернета вещей, поскольку является лишь
интерфейсом между пользователем и интернет-вещами.
На начальных этапах развития WEB’а вещей имелось некоторое
множество устройств, которые использовали протокол HTTP для отправки
данных на веб-ресурсы. При этом, находясь в одной среде, все интернетвещи использовали свой формат представления данных, который мог
распознаваться
только
определённым
типом
веб-приложений.
Таким
образом, появилась проблема стандартизации обмена информацией в WEB’е
вещей.
При
решении
данной
проблемы
основной
целью
является
обеспечение возможности интернет-вещам публиковать свои сообщения на
любом веб-ресурсе, при том условии, что каждая интернет-вещь также
является веб-ресурсом. То есть интернет-вещи должны стать частью
всемирной паутины и быть наравне с любыми другими веб-ресурсами.
В рамках решения данной проблемы был использован ряд проектов,
разработанных ранее для объединения вещей (в основном домашних
бытовых, мобильных устройств и компьютеров) в одну вычислительную
сеть, который включает в себя JINI, UPnP, DNLA и прочие. Однако
организация поддержки данных технологий в WEB’е вещей довольно
проблематична,
поскольку
требует
создания
интерфейса
между
внутрисетевыми протоколами и WEB’ом.
В результате, была выбрана технология REST (Representational State
Transfer), описывающая стиль построения архитектуры распределённых
приложений.
42
Стандарт REST был описан и популяризован в 2000 году Роем
Филдингом, одним из создателей протокола HTTP. Самой известной
системой,
построенной
в
значительной
степени
с
использованием
архитектуры REST, является современная Всемирная паутина, поэтому
данная архитектура как никакая другая подходит для организации
взаимодействия в WEB’е вещей.
Данные в REST должны передаваться в виде небольшого количества
стандартных форматов (например HTML, XML, JSON). Сетевой протокол
(как и HTTP) должен поддерживать кэширование, не должен зависеть от
сетевого слоя, не должен сохранять информацию о состоянии между парами
«запрос-ответ».
Утверждается,
что
такой
подход
обеспечивает
масштабируемость системы и позволяет ей эволюционировать с новыми
требованиями.
Противоположностью REST является подход, основанный на вызове
удаленных процедур (Remote Procedure Call — RPC). Подход RPC позволяет
использовать
небольшое
количество
сетевых
ресурсов
с
большим
количеством методов и сложным протоколом. При подходе REST количество
методов и сложность протокола строго ограничены, из-за чего количество
отдельных ресурсов может быть большим.
Использование такого подхода в Интернете вещей позволит разделить
нестандартизованные потоки данных и команд между интернет-вещами на
общепринятый поток управления и независимый поток данных, создав
общий и простой интерфейс управления интернет-вещами. Архитектура
REST позволит создать единый протокол связи интернет-вещей как с
WEB’ом, так и друг с другом, что позволит фактически расширить WEB,
включив в него Интернет вещей.
Таким образом, WEB вещей является третьим типом взаимодействия в
Интернете вещей – взаимодействием между пользователями и интернет43
вещами. Этот тип взаимодействия включает в себя не только WEB, но и
другие средства, рассмотренные в следующем разделе.
2.4. Взаимодействие между пользователями и интернет-вещами
Любая интернет-вещь должна иметь пользовательский интерфейс.
Концепция Интернета вещей подразумевает наличие у каждой вещи
конкретного адреса в сети интернет, но сетевой адрес вещи далеко не всегда
является доступным для общения с ней. Некоторые вещи могут общаться с
внешней глобальной сетью посредством шлюза и, следовательно, посылать
пакеты с одного сетевого адреса – адреса шлюза. Таким образом,
пользователь не всегда может обойтись лишь сетевым адресом, с которого
пришли последние данные от вещи. Маршрутизация в Интернете вещей
может быть абсолютно любой. Поэтому пользовательский интерфейс для
интернет-вещи должен иметь доступ к серверу управления вещами и знать
протокол взаимодействия с ним.
Пользовательский
интерфейс
интернет-вещи
–
приложение,
обладающее следующими особенностями:
- имеет графическую часть для визуального представления интернетвещи и её функций,
- имеет доступ к серверу контроля интернет-вещей и протокол
взаимодействия с ним.
Графическая часть (или графический интерфейс) вещи обычно
выполнена в виде изображения самой вещи вместе с полями данных, которые
данная интернет-вещь передаёт. Для управления вещью (отправки команд)
используются кнопки, поля ввода и прочие средства графического
интерфейса.
44
Рисунок 11. Графический интерфейс интернет-вещи (весы)
На рисунке 11 представлен графический интерфейс весов, являющихся
собственностью компании Withings, позиционирующихся как интернет-вещь
и способных передавать данные о весе пользователя в глобальную сеть.
Интерфейс имеет всего одно поле данных, отражающее информацию,
выведенную на дисплей весов в настоящий момент. Графический интерфейс
для данного устройства имеет несколько вариантов, включающих в себя
интерфейс для мобильных устройств iPhone и iPad компании (как и для всей
платформы iOS в целом), а также для социальных сетей (веб-интерфейс).
Компания Apple разрабатывает “умные вещи” в первую очередь для
взаимодействия со своими же устройствами (мобильными iPhone, iPad и
системными iMac, MacBook) и, следовательно, разрабатывает графические
интерфейсы для них.
Пользовательский
интерфейс
использования следующим образом:
45
классифицируется
по
сфере
- оконный интерфейс,
- мобильный интерфейс,
- веб-интерфейс.
Оконный графический интерфейс – используется на персональных
компьютерах с большим экраном, производительным процессором и
большим объёмом оперативной и постоянной памяти. Оконный графический
интерфейс разрабатывается для управления такими манипуляторами и
средствами ввода, как мышь, тачпад, клавиатура. Оконный графический
интерфейс обычно имеет возможность растягиваться или сжиматься в
зависимости от размеров окна и экрана, имея при этом всего одну
универсальную графическую реализацию.
Рисунок 12. Оконный графический интерфейс
Размеры графических компонентов в оконном интерфейсе обычно
небольшие, которые также могут растягиваться или сжиматься в зависимости
46
от размеров окна. В зоне видимости интерфейса часто присутствуют пустые
области больших размеров.
Мобильный графический интерфейс – используется на мобильных
устройствах (телефоны, смартфоны, планшетники) с небольшим дисплеем,
процессором средней или малой производительности и ограниченным
объёмом памяти. В качестве манипуляторов для мобильного интерфейса
выступает в основном сенсорный экран, а также джойстик и цифровая
клавиатура.
Рисунок 13. Мобильный интерфейс (метеостанция)
47
При разработке мобильных интерфейсов для сенсорных экранов особое
внимание уделяется размеру графических компонентов. Их размер должен
быть
достаточно
удобен
для
нажатия
пальцем
или
специальным
манипулятором. Такие интерфейсы, как правило, разрабатываются в
нескольких вариантах для различных типов дисплеев или устройств. При
этом реализация каждого варианта может значительно отличаться от
остальных. Это связано с тем, что одна и та же операционная система может
использоваться на разных устройствах с разными типами дисплеев и
манипуляторов.
Одна из особенностей мобильных графических интерфейсов –
сосредоточенность внимания на информации. В силу небольших размеров
экрана мобильных устройств, далеко не всегда можно уместить всю
необходимую информацию на дисплее. Заполняя свободное пространство
дисплея новыми информационными блоками важно не забывать о сложности
восприятия плохо структурированной информации. Одним из подходов к
решению проблемы размещения информации на экране мобильных
устройств является применение стиля Metro, разработанного компанией
Microsoft. Данный стиль предусматривает уменьшение деталей оформления
информационного пространства экрана с целью большей концентрации
пользователя на самой информации. Такой стиль позволяет заменить
растровую графику векторной, поскольку не нуждается в красочных деталях
оформления
и,
как
следствие,
способствует
уменьшению
объёма
используемой памяти для хранения таких интерфейсов и значительному
уменьшению нагрузки на сеть в случае использования данного стиля в вебинтерфейсах.
Веб-интерфейс – используется для отображения на веб-страницах и
сайтах сети Интернет. Использовать веб-интерфейс могут любые устройства,
имеющие выход в сеть, где расположен интерфейс и приложение – браузер.
Веб-интерфейс запрашивается браузером с удалённого сервера, в ответ на
48
что сервер выдаёт интерфейс в виде текста на языке разметки графической
информации. Основная проблема веб-интерфейсов заключается в том, что
они должны предусматривать не только различные типы браузеров, но и
типы устройств, на которых браузер запущен. Обычно веб-интерфейсы
делятся на 2 типа:
- стандартные (для персональных ПК),
- мобильные.
При этом серверная часть веб-интерфейса должна сама определить
какой графический интерфейс выдать пользователю (в зависимости от типа
пользовательского устройства). Это возможно при помощи данных, которые
клиентский браузер передаёт на сервер при запросе интерфейса. Эти данные
включают в себя:
- операционную систему устройства,
- тип браузера,
- версию операционной системы,
- версию браузера.
- тип устройства (не всегда).
49
Рисунок 14. Веб-интерфейс
Обычно веб-интерфейс имеет только одну реализацию (стандартную)
для персональных компьютеров с большими дисплеями, мышью и
клавиатурой.
Такой
вариант
используется
на
крупных
порталах,
корпоративных и персональных сайтах. В случае же с интернет-вещами этот
вариант мало приемлем. Веб-интерфейс интернет-вещей должен иметь не
только стандартную, но и мобильную часть.
Иногда веб-интерфейс имеет одну реализацию для больших дисплеев, а
для устройств с малыми экранами предлагается загрузить и установить
мобильный графический интерфейс специально для данного устройства.
Таким
образом,
требования
к
различным
типам
графических
интерфейсов имеют существенные отличия по ряду параметров.
Таблица 1. Требования к графическому интерфейсу интернет-вещей
Интерфейс
Параметр
Юзабилити
Мобильный
Оконный
интерфейс
интерфейс
Повышенное
Простота
Простота
юзабилити
использования
использования
Визуальные
Различные
размеры
варианты
Любые
50
Веб-интерфейс
Любые (разных
вариантов)
Физические
Минимальные
Любые
Небольшие
Большие текстовые
текстовые поля,
поля, небольшие
большие кнопки
кнопки
размеры
Размеры
компонентов
Число
Одна реализация
Много
реализаций
Минимальные
(универсальная)
Разные варианты
Две реализации
(стандартная и
мобильная)
Во многих источниках информации об Интернете вещей, часто
используется слово “виджет” в отношении к графическому интерфейсу
интернет-вещи. В данной работе будет часто использоваться данное
определение в том же контексте, что и графический интерфейс интернетвещи.
Виджет – это элемент графического интерфейса, содержащий в себе
информационные
и
управляющие
элементы,
объединённые
общей
принадлежностью к какой-либо сущности.
Сегодня большинство интернет-вещей представляются как небольшие
устройства с минимумом функционала (например, весы – передают только
вес пользователя, лампочка – передаёт только своё состояние - включена или
выключена). Есть и более сложные интернет-вещи (например “умный
счётчик”, передающий пользователю такие параметры, как общий расход
электроэнергии, потребляемую мощность сети, количество подключенных
устройств, их названия и т.п.). Однако большинство интернет-вещей
довольно просты и их графический интерфейс имеет минимум полей ввода и
вывода. Поэтому в отношении графического интерфейса интернет-вещей
часто применяется слово “виджет”.
51
2.4.1. Проблемы пользовательского интерфейса интернет-вещей
В настоящий момент интернет-вещей не так много, но ожидается, что
их число значительно возрастёт в ближайшие 10 лет. В связи с этим
необходимо осознавать возможные проблемы, связанные с увеличением
числа устройств в сети, избежать их и иметь меры по их предотвращению.
Одной
из
проблем
является
высокая
нагруженность
серверов
управления интернет-вещами. При этом будут иметь место следующие
факторы:
- рост числа запросов к серверу,
- рост потребления внешней памяти для хранения графических
интерфейсов,
- рост нагрузки транспортных каналов и узлов сети.
При этом если число запросов сократить без потери качества услуг
Интернета вещей не удастся, то рост потребления ресурсов серверов и
нагрузки на сеть можно значительно уменьшить, используя следующие
способы:
1) классификация интернет-вещей по типам,
2) объединение пользовательских интерфейсов общего типа в один,
3) использование сжатия,
4) использование векторной графики,
5) создание единого центра управления интернет-вещами.
Объединение интернет-вещей, их классификация и создание единого
центра управления пока не имеет активного развития. Производители
интернет-вещей предлагают свои собственные не только виджеты, но и
сервисы для управления вещами. Это может привести к усложнению
52
пользования интернет-вещами различных производителей и децентрализации
средств управления. Решение данной проблемы приблизит идею единого
центра управления, как решения появившихся проблем, к осуществлению.
Компания IBM двигается в этом направлении, предлагая не только единый
протокол взаимодействия интернет-вещей MQTT, но и единые серверы.
2.4.2. Конструктор виджетов, как решение проблем Интернета вещей
В данном разделе описывается решение двух проблем Интернета
вещей:
- рост нагрузки на сетевые ресурсы вследствие роста числа интернетвещей,
- отсутствие единого центра управления интернет-вещами.
Решая проблему нагрузки ресурсов сети нужно выполнить следующие
задачи:
1) уменьшить объём передаваемых данных по сети,
2) минимизировать рост потребности в вычислительных ресурсах.
Рост нагрузки на сеть вызывается ростом числа обособленных
интернет-вещей.
Каждая
вещь
должна
иметь
модуль
управления
(программную реализацию) и графический интерфейс. Если первое легко
поддаётся объединению и минимизации потребления памяти, то второе
гораздо
сложнее,
поскольку
все
вещи,
несмотря
на
возможность
классификации, индивидуальны и имеют свой внешний вид, отражение
которого в графическом интерфейсе является одним из интересов
производителей интернет-вещей.
53
В качестве решения данной проблемы предлагается использование
конструктора виджетов интернет-вещей. Данный конструктор позволяет:
- выбрать графический веб-интерфейс для виджета из широкого
набора (в т.ч. выбрать интерфейс производителя);
- объединить виджеты в группу для отображения на одном рабочем
пространстве;
- построить графический веб-интерфейс вручную, используя набор
графических компонентов.
Данное решение рассматривается как совокупность веб-технологий и
методов их использования.
Рассматриваемый конструктор виджетов является веб-приложением и
разрабатывается как элемент управления интернет-вещами с помощью
браузера, поэтому позволяет построить лишь веб-интерфейсы, что даёт ему
следующие преимущества:
- возможность использования в едином центре управления интернетвещами,
- независимость от платформы и устройства, с которого произведён
запуск конструктора.
Решение
проблемы
роста
нагрузки
в
контексте
графических
интерфейсов возможно также и без конструктора виджетов, путём
выполнения задач классификации вещей и объединения их в обобщённые
группы для стандартизации интерфейсов. Однако любая стандартизация
графических образов отрицательно сказывается на восприятии человеком.
Конструктор виджетов даст возможность не только внести разнообразие в
графические интерфейсы без ощутимого роста нагрузки на сеть, но и
позволит пользователям абстрагироваться от стандартизации, предоставляя
им средства для создания своих собственных интерфейсов.
54
Стоит
отметить
важную
особенность
конструктора
виджетов,
заключающуюся в том, что он позволяет создавать не только виджеты, но и
группы виджетов, объединяя в одном визуальном пространстве сразу
несколько графических интерфейсов различных интернет-вещей. Такая
особенность
позволит
объединить
различных
производителей,
абсолютно
любые
поддерживающих
интернет-вещи
единый
протокол
взаимодействия. Однако отсутствие единого протокола, поддерживаемого
всеми производителями интернет-вещей является проблемой, оказывающей
влияние и на конструктор виджетов. Разработка конструктора виджетов
позволит обратить большее внимание на данную проблему.
2.4.2.1. Описание конструктора
Конструктор виджетов представляет собой веб-приложение, состоящее
из двух основных частей:
- серверная часть,
- клиентская часть.
Клиентская часть приложения берёт на себя функции:
- отображение графического интерфейса,
- приём команд от пользователя и передача их серверной части,
- приём команд от сервера и обновление графического интерфейса,
- бизнес-логика конструктора виджетов.
Серверная часть выполняет следующие функции:
- обработка команд пользователя и передача их на сервер управления
интернет-вещами для последующей маршрутизации команды к
устройству,
- принятие команд от сервера управления вещами и трансляция их на
клиентскую часть для обновления графического интерфейса,
55
- ядро конструктора виджетов (обработка команд от бизнес-логики
конструктора виджетов, сохранение информации о виджетах в БД),
- авторизация и аутентификация пользователя.
Рисунок 15. Функциональная диаграмма конструктора виджетов
Бизнес-логика
конструктора
отвечает
за
функции
управления
графическими компонентами при построении виджета пользователем. Все
изменения, произведённые пользователем, бизнес-логика сообщает на сервер
в ядро конструктора.
56
Ядро
конструктора
принимает
информацию
от
бизнес-логики,
обрабатывает её, сохраняет в базу данных или выдаёт необходимые данные.
При построении виджет привязывается к конкретной вещи и для получения
данных о ней ядро может запросить их у модуля данных.
Модуль данных берёт на себя функцию получения данных от
интернет-вещей и отправления команд, адресованных им от пользователя.
Модуль данных состоит из клиентской и серверной частей. Данные
принимаются и передаются посредством сервера управления интернетвещами.
Серверная
часть
необходима
для
инкапсуляции
логики
взаимодействия клиентской части с сервером управления интернет-вещами.
Поля данных графического интерфейса заполняются с помощью модуля
данных. При вводе команд в графический интерфейс происходит трансляция
их в модуль данных.
Графический интерфейс веб-приложения конструктора виджетов
включает в себя:
- графический интерфейс конструктора,
- собираемые графические интерфейсы интернет-вещей.
Обе составные части используют одни и те же технологии с той лишь
разницей, что собираемые графические интерфейсы отличаются меньшим
объёмом занимаемой памяти.
Сервер управления вещами – объединяет в себе авторизацию
интернет-вещей, разграничение прав доступа к ним, а также поддержку
протокола обмена информацией между вещами.
2.4.2.2. Используемые технологии
Серверная часть веб-приложения разрабатывается с использованием
технологии PHP и располагается на удалённом сервере.
57
PHP – скриптовый язык программирования, используемый в основном
для разработки серверных приложений.
PHP был выбран в качестве средства серверной разработки по
следующим причинам:
- распространяется в свободном доступе,
- подходит для любых современных серверов,
- имеет хорошую документацию и множество примеров
использования,
- простота развёртывания,
- гибкие средства работы с БД,
- простой синтаксис,
- большинство CMS написаны с помощью PHP (следовательно,
разрабатываемые модули могут быть совместимы с данными CMS).
Для работы с базами данных была выбрана технология MySQL,
поскольку
она
является
свободно
распространяемым
продуктом,
обеспечивает отличную производительность и хорошо поддерживается
языком PHP. База данных конструктора виджетов располагается на том же
сервере, что и серверная часть.
Клиентская часть сочетает в себе такие технологии, как JavaScript,
JQuery, HTML, CSS и предназначена для выполнения на клиентских веббраузерах.
Современные веб-браузеры используют три уровня представления данных:
- структура,
- внешний вид,
- бизнес-логика.
Такое представление данных соответствует популярной концепции
MVC (Model View Controller–модель, представление, управление), имея
58
некоторые расхождения с ней, и для каждого уровня используется своё
средство.
Структура веб-приложения описывается с помощью языка разметки
гипертекстовой информации HTML. Стоит отметить, что бизнес-логика и
внешний вид веб-приложения могут быть описаны непосредственно в тексте
HTML. Несмотря на то, что можно описывать каждый уровень в отдельном
файле, они все объединены в тексте HTML. В этом заключается
несоответствие концепции MVC.
Внешний вид приложения описывается с помощью так называемых
таблиц стилей средствами технологии CSS. Данная технология используется
для описания стилей, применимых к объектам, описанным на языке HTML.
Стили объектов могут быть описаны непосредственно в тексте HTML, но
CSS – это технология, созданная с целью отделить описание внешнего вида
объекта от его структуры.
Для описания бизнес-логики веб-приложения используется технология
JavaScript – распространённый язык программирования, используемый в
основном для описания логики поведения каких-либо объектов. Он
используется во многих программных продуктах, в игровой индустрии, в
различных средствах разработки. JavaScript также используется и в веббраузерах как язык описания бизнес-логики веб-страницы.
JQuery – технология, позволяющая значительно упростить разработку
веб-приложений на основе языка JavaScript. JQuery представляет собой
фреймворк, написанный на языке JavaScriptи содержащий множество часто
используемых функций и алгоритмов, реализованных в виде простых
методов. JQuery замечательно подходит для работы с визуализацией
графических компонентов интерфейса, а также упрощает работу с запросами
к удалённым сетевым узлам.
59
Фреймворк (англ. framework — каркас, структура) — структура
программной системы; программное обеспечение, облегчающее разработку и
объединение
разных
компонентов
большого
программного
проекта.
Употребляется также слово «каркас», а некоторые авторы используют его в
качестве основного, в том числе не базируясь вообще на англоязычном
аналоге. Можно также говорить о каркасном подходе как о подходе к
построению программ, где любая конфигурация программы строится из двух
частей: первая, постоянная часть — каркас, не меняющийся от конфигурации
к конфигурации и несущий в себе гнезда, в которых размещается вторая,
переменная часть — сменные модули (или точки расширения).
Визуализация с помощью JQuery позволяет с лёгкостью описывать
анимацию графических компонентов, изменение их размеров, цвета, формы.
Работа с удалёнными узлами также упрощается благодаря использованию
технологии AJAX.
AJAX (AsynchronousJavaScriptandXML) - подход к построению
интерактивных
пользовательских
интерфейсов
веб-приложений,
заключающийся в «фоновом» обмене данными браузера с веб-сервером. В
результате, при обновлении данных веб-страница не перезагружается
полностью, и веб-приложения становятся быстрее и удобнее.
JQueryупрощает и эту технологию, сводя её использование к вызову
простой функции с минимумом параметров.JQueryне только упрощает
программирование на JavaScript, но и делает его более безопасным, а также
хорошо поддерживает кроссбраузерность.
Кроссбраузерность — свойство сайта отображаться и работать во всех
популярных
браузерах
идентично.
Под
идентичностью
понимается
отсутствие развалов верстки и способность отображать материал с
одинаковой степенью читабельности. Понятие «кроссбраузерность» очень
60
часто путают с попиксельным соответствием, что на самом деле является
разными понятиями.
Некоторые интернет-вещи требуют поддержки обмена данными в
реальном времени (например – видеорегистратор, микрофон и т.п.). Поэтому
в Интернете вещей стоит проблема данных реального времени.
Существует 2 способа обмена информацией между клиентской частью
веб-приложения и серверной:
1) поллинг (опрос),
2) непрерывный канал связи.
Первый способ используется чаще всего в случае, когда частота
обновления данных не так актуальна. Такой подход не желателен для систем
реального времени. Однако такой подход является единственным выходом в
случае плохого качества связи. К недостаткам такого подхода можно отнести
наличие накладных расходов при каждой установке соединения.
Второй способ позволяет избежать накладных расходов, связанных с
установкой соединения, поскольку соединение устанавливается в таком
случае всего один раз. В период установленного соединения обе стороны
могут обмениваться сообщениями любой длины. Такой способ используется
в случае частого обновления данных и повышенных требований к
актуальности данных и скорости реагирования системы. В системах
реального времени такой способ незаменим.
Сравнивая два способа, применимо к Интернету вещей, становится
очевидным, что использование второго способа является лучшим решением
задачи обмена данными между клиентской и серверной частью вебприложения. Такой способ решает проблему передачи видео и аудио
информации с интернет-вещей, а также позволяет при минимальной нагрузке
61
на сеть обеспечить своевременный вывод информации на дисплей
пользовательского устройства.
Для реализации непрерывного канала связи в веб-приложениях
существует специальная технология – WebSocket.
WebSocket
—
протокол
полнодуплексной
связи
поверх
TCP-
соединения, предназначенный для обмена сообщениями между браузером и
веб-сервером в режиме реального времени.
В
настоящее
время
в
W3C
осуществляется
стандартизация
WebSocketAPI. Также протокол WebSocket был стандартизован IETF как
RFC 6455.
Технология WebSocket предназначена для реализации в веб-браузерах
и веб-серверах, но может быть использована в любых клиент-серверных
приложениях. Протокол WebSocket является независимым и основан на TCPпротоколе. Его единственная связь с HTTP в том, что рукопожатие
обрабатывают серверы HTTP как запрос на обновление. Протокол WebSocket
делает возможным более тесное взаимодействие между браузером и вебсайтом, позволяет реализовать более «живой» контент (например, игры
реального
времени).
Это
стало
возможным
через
предоставление
стандартного способа для отправки содержимого сервером браузеру без
дополнительного запроса клиента, и позволяет передавать сообщения туда и
обратно, пока соединение открыто. Таким образом, между браузером и
сервером может происходить двусторонний (двунаправленный) обмен
сообщениями. Аналогичный эффект был достигнут нестандартным образом в
таких технологиях, как Comet.
Кроме того, обмен информацией идёт по TCP-порту 80, и это большое
преимущество для тех сред, которые блокируют нестандартные подключения
к интернету с помощью межсетевого экрана. В настоящее время протокол
62
Web Socket поддерживается в нескольких браузерах, включая Google Chrome,
Firefox, Safari, Opera и Internet Explorer (начиная с 10 версии). WebSocket
также требует поддержки веб-приложений на стороне сервера.
Существует ряд других веб-технологий, позволяющих разрабатывать
веб-виджеты. В этот список можно включить ASP.NET, Java, Adobe
Flash/Flex.Данные технологии объединены общим подходом – клиентская и
серверная части приложения разрабатываются с помощью одной технологии
и объединены в одно целое веб-приложение. Рассмотрим эти технологии и
сравним их с используемыми в конструкторе виджетов.
Java – технология, разработанная компанией Sun Microsystems и в
настоящий
момент
являющаяся
собственностью
компании
Oracle,
используется в разных сферах разработки программного обеспечения (в том
числе и системного). Для разработки веб-приложений с помощью средств
Javaразрабатывается два приложения – сервлет (серверная часть) и апплет
(клиентская часть). Данный подход достаточно удобен, поскольку разработка
ведётся на одном языке. Однако Java имеет такой недостаток, как
относительно высокие требования к производительности и наличие среды
выполнения команд Java Virtual Machine. Несмотря на это, веб-приложения,
написанные на Java имеют большие возможности визуализации и доступа к
данным пользовательского устройства. Но для виджетов интернет-вещей
такая гибкость не оправдывает те накладные расходы, получаемые взамен.
Flash – технология, разработанная компанией Adobe, позволяет
создавать веб-приложения без разделения на серверную и клиентскую части.
Приложение такого типа загружается на устройство пользователя при
запросе и выполняется специальной программной средой Adobe Flash Player.
Такой подход позволяет делать достаточно гибкие веб-приложения с
большими возможностями визуализации и доступа к системным ресурсам.
Однако размер таких веб-приложений становится достаточно большим и
63
приложения становятся слишком требовательными к вычислительным
ресурсам. Такой подход не оправдывает себя при разработке веб-виджетов
для интернет-вещей.
ASP.NET – технология, разработанная компаниейMicrosoft–позволяет
разрабатывать веб-приложения в среде Visual Studio. При этом приложение
не делится на клиентскую и серверную часть. Программист просто
описывает
визуальную
часть
и
её
бизнес-логику,
которые
потом
компилируются в одно приложение. При вызове такого приложения сервер
генерирует пользовательский интерфейс в привычном виде – HTML + CSS +
JavaScript и выдаёт его пользователю. Недостатком такого подхода является
то, что веб-приложение и его внешний вид сильно зависят от текущего
состояния фреймворка ASP.NET. Ещё одним недостатком является плохая
поддержка системами не из семейства Windows.
2.4.2.3. Примеры веб-виджетов
В данном разделе представлены графические интерфейсы интернетвещей, являющиеся примерами разрабатываемых с помощью конструктора
виджетов.
Такие
виджеты
могут
заменить
множество
аналогичных
объединив при этом все интернет-вещи, например, в одном доме, для
управления в едином центре.
Представленные в данном разделе веб-виджеты применимы к
реальным интернет-вещам, разрабатываемым в лаборатории беспроводных
сенсорных сетей WiSeNet Lab кафедры ВСиС.
В приложении имеется исходный код на языках HTML, CSS и
JavaScript для данных виджетов.
Умная розетка
64
Одно из применений интернет-вещей – управление электропитанием в
доме. Для выполнения данной задачи существует специальная интернет-вещь
– умная розетка, выпускаемая на рынке в настоящее время многими
компаниями, например Sony, ThinkEco, Powerhouse Dynamics, Ube. Данное
устройство позволяет дистанционно управлять питанием розетки при
помощи пультов управления или веб-интерфейса.
Рисунок 16. Веб-виджет умной розетки в двух состояниях
Управление розеткой с помощью такого виджета осуществляется
путём простого нажатия на виджет. При этом состояние розетки меняет своё
значение на противоположное (вкл./выкл.).
Лампы освещения
Управление электропитанием в доме возможно не только с помощью
розеток, но и при помощи умных ламп, позволяющих управлять освещением.
Компания Philips разработала лампы Hue, управляемые дистанционно.
Внутри таких ламп имеется беспроводной микроконтроллер, принимающий
65
команды от пульта, располагаемого обычно на стене. Такие лампы получили
дальнейшее развитие в Интернете вещей. Компания Apple использует
приложения для управления ими в своих смартфонах. Данными лампами
также возможно управлять с помощью центра управления в WEB’е. Лампу
достаточно вкрутить вместо обычной и установить пульт управления или
шлюз где-либо в радиусе действия приёмопередатчика лампы. Кроме того,
такие лампы имеют возможность регулировки цвета освещения.
Рисунок 17. Виджет для ламп освещения
На рисунке представлена группа из трёх виджетов для управления
лампой. Каждая лампа, как интернет-вещь, имеет свой идентификатор, к
которому можно привязать описание, говорящее о принадлежности лампы к
той или иной комнате или месту в доме. С помощью конструктора виджетов
можно создать группу из любого количества ламп, полностью управляя
освещением в доме.
66
Для управления лампами используется палитра цветов, элемент вызова
которой расположен рядом с каждой лампой. Выбирая цвет из палитры,
управляемая лампа меняет цвет своего освещения на выбранный. Имеется
также и переключатель цвета всех ламп одновременно. Для управления
питанием лампы (включения и выключения) используются белый и чёрный
цвета в палитре.
Метеостанция
В настоящий момент метеостанции разрабатываются с возможностью
управления и мониторинга из Интернета, т.е. как интернет-вещи. Наиболее
выдающееся решение на данный момент принадлежит компании Netatmo Urban Weather Station.
Рисунок 18. Виджет метеостанции
На рисунке 18 изображён веб-интерфейс, который использует данные,
приходящие с метеостанции и отображает на визуальном пространстве
экрана.
Данный виджет представляет собой пример составного виджета, т.е.
виджета, на котором отображается несколько источников информации. В
67
данном
случае
все
источники
информации
(давление,
температура,
влажность, шум) принадлежат одному устройству – метеостанции. Однако
один виджет может сочетать в себе данные с разных устройств.
Используя конструктор виджетов можно собирать виджет для
устройства, имеющего несколько источников данных и отображать только
нужные пользователю.
Электросчётчик
Существует множество примеров сочетания беспроводных технологий
и устройств изменения параметров сети питания. Один из них –
использование электросчётчика в качестве интернет-вещи. В таком случае
все данные со счётчика (напряжение в сети, ток, общая потребляемая
мощность, общий расход) можно наблюдать со специальной веб-страницы в
Интернете.
68
Рисунок 19. Виджет электросчётчика
Кроме того, такой электросчётчик способен идентифицировать
подключенное к нему устройство.
2.4.3. Выводы
В настоящее время веб-интерфейсы имеют большие возможности
визуализации. Средства, позволяющие использовать эти возможности,
способны создать любой тип графического интерфейса (оконный или
мобильный) на веб-странице, открытой веб-браузером.
69
Благодаря выбору технологий HTML, CSS и JavaScript, веб-виджет
становится универсальным графическим интерфейсом, который можно
встроить в любой сайт, а также использовать для интерпретации любым
клиентским устройством, поскольку эти три технологии дают 3 составные
части любого веб-приложения:
- структура,
- внешний вид,
- бизнес-логика.
Представленный конструктор веб-виджетов позволяет превратить
массу
графической
растровой
информации
в
векторную,
а
также
предотвращает дублирование растровой графической информации, решая
проблему нагрузки на сетевые узлы и каналы.
Кроме
того,
конструктор
виджетов
позволяет
предоставить
пользователю возможность самому задавать внешний вид виджетов для
интернет-вещей, а также объединять веб-виджеты в группы.
Основной проблемой конструктора виджетов является факт отсутствия
в
настоящий
момент
единого
протокола
для
Интернета
вещей,
поддерживаемого всеми производителями. Это не позволит использовать
такой конструктор в сочетании с интернет-вещами многих производителей.
Однако разработка конструктора виджетов позволит заострить данную
проблему и приблизить идею создания единого центра управления интернетвещами к реальности.
Представление
графической
информации
в
векторном
виде
в
настоящий момент находит широкое распространение благодаря появлению
и
популяризации
стиля
Metro
и
развитию
облачных
технологий.
Предполагается, что в ближайшем будущем облачные технологии позволят
полностью
перенести
вычислительные
70
мощности
персональных
компьютеров в облако без ощутимых изменений в производительности. Это
позволит более рационально использовать вычислительные ресурсы и
сделать
вычислительный
процесс
мобильным.
Развитию
данного
направления способствуют исследования и разработки в области графики и
представления информации. Использование векторной графики достаточно
актуально.
Таким образом, веб-интерфейсы являются наиболее универсальным
видом графических интерфейсов. Технологии HTML, CSS, JavaScript
являются лишь средствами представления информации и могут быть
использованы не только в веб-интерфейсах, но и в любых других. Создание
веб-интерфейса для устройства или узла глобальной сети даёт на выходе не
только веб-приложение, доступное при наличии доступа к сети Интернет, но
и полную структуру приложения с визуальной частью и бизнес-логикой,
которая
может быть использована в любом локальном системном
приложении при поддержке им данных технологий.
71
Заключение
В работы были рассмотрены 3 основных вида взаимодействия в
Интернете вещей:
1. Взаимодействие между сервером и интернет-вещами.
2. Взаимодействие интернет-вещей друг с другом.
3. Взаимодействие пользователей с интернет-вещами.
Были даны способы организации данных видов взаимодействия, и выявлены
следующие проблемы Интернета вещей:
1. Отсутствие общепринятого протокола для взаимодействия интернетвещей друг с другом.
2. Отсутствие
поддержки
существующими
решениями
технологии
туманных вычислений.
3. Отсутствие общепринятого метода интеграции интернет-вещей в WEB.
В качестве решения первой проблемы предлагается использование
протокола MQTT. В настоящий момент данный протокол используется в
большинстве систем интернет-вещей, однако используется не повсеместно,
поскольку поддерживается не всеми выпускаемыми интернет-вещами.
Протокол MQTT позиционируется именно как протокол для Интернета
вещей и ему отдаётся предпочтение, поскольку он разрабатывался с целью
обеспечения минимального энергопотребления и минимизации объёма
передаваемой информации.
Использование протокола MQTT порождает вторую проблему невозможность использования технологии туманных вычислений, поскольку
он не предусматривает методов взаимодействия в локальных сетях вещей.
Протокол распространяется только на связь интернет-вещей с серверомброкером. В качестве решения данной проблемы были предложены 2
способа:
72
- метод локального брокера,
- метод псевдо-сервера.
В результате анализа данных решений, наиболее приемлемым
оказывается метод локального брокера, поскольку он обладает следующими
особенностями:
- решение не требует внесения изменений в протокол MQTT,
- достаточно лишь введение новых типов узлов в локальную сеть
вещей – локальных брокеров.
Недостатками данного метода являются:
- невозможность организации ячеистой топологии,
- дополнительные расходы на внесение новых узлов в локальную
сеть.
Однако данные недостатки окупаются лёгкостью встраивания такого
решения в существующие системы интернет-вещей.
Метод
псевдо-сервера
позволяет
избавиться
от
перечисленных
недостатков, однако требует серьёзных изменений реализации сервера и
клиента MQTT, а также внесения изменений в протокол. Несмотря на то, что
такие изменения не повлияют на обратную совместимость, они являются
надстройкой над протоколом и более правильной альтернативой данному
способу будет доработка протокола MQTT с целью обеспечить поддержку
туманных вычислений.
Был произведён обзор методов взаимодействия интернет-вещей с
пользователями и выявлена третья проблема Интернета вещей – отсутствие
общепринятого метода интеграции интернет-вещей в WEB. В качестве
решения данной проблемы предлагается использование архитектуры REST.
Данная архитектура позволяет создать WEB вещей, состоящий из устройств,
способных взаимодействовать с любым WEB-ресурсом, поскольку будет
73
использоваться единая технология обмена информацией, ориентированная на
данные и основанная на протоколе HTTP.
Была оценена проблема роста нагрузки на сетевые ресурсы вследствие
роста числа интернет-вещей. Главную часть проблемы составляет рост
нагрузки
на
классификации
сервера
управления
интернет-вещей
и
интернет-вещами.
общих
стандартов
Отсутствие
графических
интерфейсов порождает проблему децентрализации средств доступа к
интернет-вещам. Решением данной проблемы является создание единого
сервера управления интернет-вещами. В качестве шага на пути к решению
данной проблемы предложено использование конструктора виджетов,
который позволяет:
- классифицировать интернет-вещи и объединить множество схожих
графических интерфейсов,
- значительно уменьшить объём занимаемой памяти графическими
интерфейсами,
- создавать интерфейсы с возможностью встраивания в любой вебресурс,
- создавать графические интерфейсы с желаемым внешним видом.
В ходе исследования данного решения были рассмотрены технологии,
позволяющие создавать веб-приложения, произведён их сравнительный
анализ и выбраны оптимальные технологии для разработки веб-виджетов
интернет-вещей и самого конструктора виджетов. Использование технологий
HTML, CSS, JavaScript, JQuery в связке даёт возможность обеспечить:
- минимальный физический размер виджета,
- максимальную интегрируемость в веб-ресурсы,
- минимальные требования к производительности и наличию ПО
пользовательских устройств.
74
Используемая литература
1. Кнеллер В.Ю - "Приборное облако" – концепция функционирования
сенсорных систем на основе интернет-технологии // Датчики и системы
№8, 2010 (66-69).
2. D. Guinard, V. Trifa, E. Wilde - A resource oriented architecture for the Web
of Things // Internet of Things (IoT), 2010 (Tokyo, Japan).
3. D. Guinard, V. Trifa, T. Pham, O. Liechti - Towards physical mashups in the
Web of Things // Proc. of the Sixth International Conference on Networked
Sensing Systems, (INSS), 2009.
4. A. Bufalino, S. Spanghero - M2M in the Cloud: It´s the Right Place,
September, 2011 [Электронный ресурс]. URL:
http://www.telit.com/en/discover/market-intelligence/telit-m2mcolumn/archive.php?p_id=359&id_to_show=12
5. Kevin Ashton - That ‘Internet of Things’ Thing. In the real world, things
matter more than ideas.
6. Rob van Kranenburg - The Internet of Things: A critique of ambient
technology and the all-seeing network of RFID.
7. Disruptive Civil Technologies - Six Technologies with Potential Impacts on
US Interests out to 2025
8. Леонид Черняк - Платформа Интернета вещей (рус.). Открытые системы.
СУБД, №7, 2012
9. А.Д. Скороходов. - Способы территориального объединения сенсорных
сетей.
10.Пилипенко Н.А. - WEB вещей – новый этап развития интернета вещей.
11.Восков Л.С - Интернет вещей // "Новые информационные технологии".
Тезисы докладов XX Международной студенческой конференции-школысеминара, М.: МИЭМ, 2012 (89-94).
12.http://evrythng.net – инструмент для интеграции интернет-вещей в
социальные сети.
75
13.http://www.sierrawireless.com/productsandservices/AirVantage.aspx AirVantage M2M Cloud Platform.
14.http://www.netatmo.com - метеостанция Netatmo Weather Station.
15.http://www.withings.com – интернет-вещи компании Withings.
76
Приложения
Приложение 1. Исходный код веб-виджета ламп освещения
<style>
.widget_image{
position:absolute;
}
.lamp_image{
z-index:20;
background-image: url("lamps/images/lamp.png");
width:100px;
height:168px;
}
.widget_color{
position:relative;
left:1px;
top:1px;
z-index:10;
height:166px;
width:98px;
text-align:center;
/*background-color:#00ff00;*/
}
.object_container{
position:absolute;
}
77
.iColorPicker{
width:80%;
}
.control{
width:100%;
margin-top:5px;
}
.colorpicker_base{
display:none;
}
</style>
<select class="colorpicker_base" a>
<!-- Colors from Google Calendar -->
<option value="#ffffff">On</option>
<option value="#7bd148">Green</option>
<option value="#5484ed">Bold blue</option>
<option value="#a4bdfc">Blue</option>
<option value="#46d6db">Turquoise</option>
<option value="#7ae7bf">Light green</option>
<option value="#51b749">Bold green</option>
<option value="#fbd75b">Yellow</option>
<option value="#ffb878">Orange</option>
<option value="#ff887c">Red</option>
<option value="#dc2127">Bold red</option>
<option value="#dbadff">Purple</option>
78
<option value="#e1e1e1">Gray</option>
<option value="#000000">Off</option>
</select>
<script>
var Widget;
function WLamps()
{
this.getData = function(param)
{
var _url = 'getdata.php?widget=lamps&param=' + param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
this.sendData = function(__data, param)
{
var _url = 'setdata.php?widget=lamps&param=' + param;
$.post(_url, {data:__data}, function(_data){}, 'html');
}
79
this.visualLampSetColor = function(lampId, color)
{
if(lampId)
$('#lamp' +
lampId).find('.widget_color').css('background-color', color);
else
$('.widget_color').css('background-color', color);
}
this.lampSetColor = function(lampId, color)
{
this.sendData('{"value":"false"}', 'hueisgroup');
this.sendData('{"value":"' + lampId + '"}', 'subid');
this.sendData('{"value":"' + color + '"}', 'color');
}
this.lampsSetColor = function(color)
{
this.sendData('{"value":"true"}', 'hueisgroup');
this.sendData('{"value":"' + color + '"}', 'color');
}
this.lampsOn = function()
{
this.sendData('{"value":"true"}', 'hueisgroup');
this.sendData('{"value":"true"}', 'on');
}
this.lampsOff = function()
80
{
this.sendData('{"value":"true"}', 'hueisgroup');
this.sendData('{"value":"false"}', 'on');
}
this.lampOn = function(lampId)
{
this.sendData('{"value":"' + lampId + '"}', 'subid');
this.sendData('{"value":"true"}', 'on');
}
this.lampOff = function(lampId)
{
this.sendData('{"value":"' + lampId + '"}', 'subid');
this.sendData('{"value":"false"}', 'on');
}
}
$(document).ready(function(){
Widget = new WLamps();
for(var i = 1; i <= 3; i++)
{
Widget.sendData('{"value":"false"}', 'hueisgroup');
Widget.sendData('{"value":"' + i + '"}', 'subid');
Widget.getData('color', function(value){
81
if(value.length == 6)
Widget.visualLampSetColor(i, '#' + value);
});
}
});
</script>
<div class="object_container" id="lamp1" lampid="1"
style="top:20px;left:30px">
<div class="widget_image lamp_image"></div>
<div class="widget_color"></div>
<div class="control"></div>
</div>
<div class="object_container" id="lamp2" lampid="2"
style="top:60px;left:230px">
<div class="widget_image lamp_image"></div>
<div class="widget_color"></div>
<div class="control"></div>
</div>
<div class="object_container" id="lamp3" lampid="3"
style="top:30px;left:430px">
<div class="widget_image lamp_image"></div>
<div class="widget_color"></div>
82
<div class="control"></div>
</div>
<div class="control"></div>
<script>
$('.control').append('<select class="colorpicker_container">' +
$('.colorpicker_base').html() + '</div>');
$('.colorpicker_container').simplecolorpicker();
$('.colorpicker_container').simplecolorpicker('selectColor', '#7bd148');
$('.colorpicker_container').simplecolorpicker('destroy');
$('.colorpicker_container').simplecolorpicker({
picker: true
}).on('change', function() {
var container = $(this).parent().parent();
var color = $(this).val();
var lampId = parseInt(container.attr('lampid'));
switch(color)
{
case '#000000':
lampId != NaN ? Widget.lampOff(lampId) :
Widget.lampsOff();
break;
case '#ffffff':
lampId != NaN ? Widget.lampOn(lampId) :
Widget.lampsOn();
break;
83
default:
lampId ? Widget.lampSetColor(lampId, color.substr(1)) :
Widget.lampsSetColor(color.substr(1));
Widget.visualLampSetColor(lampId, color);
break;
}
});
</script>
Приложение 2. Исходный код веб-виджета для умных весов
<style>
.widget_image{
position:absolute;
}
.scale_image{
z-index:10;
background-image: url("scale/images/scale.png");
width:670px;
height:673px;
}
.widget_text{
position:relative;
left:270px;
top:55px;
z-index:20;
font-size:40px;
84
font-family:tahoma;
font-weight:bold;
color:#faf7f5;
height:40px;
width:100px;
text-align:center;
}
.object_container{
position:absolute;
}
</style>
<script>
var interval;
var Widget;
function WScale()
{
this.parseWeight = function(_data)
{
return parseFloat(_data);
}
this.setWeight = function(_weight)
{
$(".widget_text").html(_weight);
}
85
this.getData = function(param, _callback)
{
var _url = 'getdata.php?widget=scale&param=' + param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
}
function scale_getDataRecursive()
{
Widget.getData('weight', function(val){
parsedWeight = Widget.parseWeight(val.replace(/[,]+/g,
'.')).toFixed(2);
if(parsedWeight > 0)
Widget.setWeight(parsedWeight);
});
clearInterval(interval);
interval = setInterval(scale_getDataRecursive, 1000 );
}
$(document).ready(function(){
Widget = new WScale();
Widget.setWeight(0);
scale_getDataRecursive();
});
86
</script>
<div class="object_container">
<div class="widget_image scale_image"></div>
<div class="widget_text"></div>
</div>
Приложение 3. Исходный код веб-виджета умной розетки
<style>
.widget_image{
position:absolute;
}
.outlet_image{
z-index:10;
background-image: url("outlet/images/outlet_off.jpg");
width:220px;
height:248px;
}
.object_container{
position:absolute;
}
.outlet{
cursor:pointer;
}
</style>
87
<script>
var Widget;
function WOutlet()
{
this.sendData = function(__data, param)
{
var _url = 'setdata.php?widget=outlet&param=' + param;
$.post(_url, {data:__data}, function(_data){}, 'html');
}
this.getData = function(param, _callback)
{
var _url = 'getdata.php?widget=outlet&param=' + param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
this.visualOutletOn = function()
{
var w = $('.outlet');
w.find('.outlet_image').css('background-image',
'url("outlet/images/outlet_on.jpg")');
w[0].state = 1;
88
}
this.visualOutletOff = function()
{
var w = $('.outlet');
w.find('.outlet_image').css('background-image',
'url("outlet/images/outlet_off.jpg")');
w[0].state = 0;
}
this.outletOn = function()
{
this.sendData('{"value":"1"}', 'power');
this.visualOutletOn();
}
this.outletOff = function()
{
this.sendData('{"value":"0"}', 'power');
this.visualOutletOff();
}
this.outletGetState = function()
{
return getData('power');
}
}
$(document).ready(function(){
89
Widget = new WOutlet();
Widget.getData('power', function(_state){
switch(_state)
{
case '1':
Widget.visualOutletOn();
break;
case '0':
Widget.visualOutletOff();
break;
default:
Widget.visualOutletOff();
break;
}
});
$('.outlet').click(function(){
switch(this.state)
{
case 1:
Widget.outletOff();
break;
case 0:
Widget.outletOn();
break;
}
90
});
});
</script>
<div class="object_container outlet">
<div class="widget_image outlet_image"></div>
</div>
<img src="outlet/images/outlet_on.jpg" style="display:none"/>
<img src="outlet/images/outlet_off.jpg" style="display:none"/>
Приложение 4. Исходный код веб-виджета метеостанции
<style>
.object_container{
}
.meteo_text{
color:#7f92a5;
}
.meteo_tempereture{
top:2px;
left:15px;
font-size:50px;
}
.meteo_humidity{
top:-35px;
91
left:174px;
font-size:20px;
}
.meteo_pression{
top:-15px;
left:174px;
font-size:19px;
}
.meteo_co2{
top:-48px;
left:45px;
font-size:32px;
}
.meteo_noise{
top:-36px;
left:20px;
font-size:38px;
}
.meteostation div{
position:relative;
}
.meteostation{
width:256px;
height:157px;
92
font-family:'MS Sans Serif', Geneva, sans-serif;
background-image:url("meteostation/images/Meteostation_min.jpg");
}
</style>
<script>
var interval;
var Widget;
function WMeteostation()
{
this.getData = function(param, _callback)
{
var _url = 'getdata.php?widget=meteostation&param=' + param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
this.setTemperature = function(val)
{
$('.meteo_temperature').html(val);
}
93
this.setHumidity = function(val)
{
$('.meteo_humidity').html(val);
}
this.setCO2 = function(val)
{
$('.meteo_co2').html(val);
}
this.setNoise = function(val)
{
$('.meteo_noise').html(val);
}
this.setPression = function(val)
{
$('.meteo_pression').html(val);
}
var t = this;
this.getAllData = function()
{
t.getData('Temperature', function(val){
t.setTemperature(val);
});
94
t.getData('Humidity', function(val){
t.setHumidity(val);
});
t.getData('Co2', function(val){
t.setCO2(val);
});
t.getData('Pressure', function(val){
t.setPression(val);
});
t.getData('Noise', function(val){
t.setNoise(val);
});
}
}
function meteostation_getDataRecursive()
{
Widget.getAllData();
clearInterval(interval);
interval = setInterval(meteostation_getDataRecursive, Math.floor(
2000 ) );
}
95
$(document).ready(function(){
Widget = new WMeteostation();
meteostation_getDataRecursive();
});
</script>
<!-* Temperature : Celsius
* Humidity : %
* Co2 : ppm
* Pressure : mbar
* Noise : db
-->
<div class="object_container">
<div class="meteostation">
<div class="meteo_tempereture meteo_text">25</div>
<div class="meteo_humidity meteo_text">90</div>
<div class="meteo_pression meteo_text">1030</div>
<div class="meteo_co2 meteo_text">1102</div>
<div class="meteo_noise meteo_text">69</div>
</div>
</div>
Приложение 5. Исходный код веб-виджета электросчётчика
<style>
.object_container{
position:absolute;
}
.consumption{
96
padding:10px;
border-top:2px solid #ffffff;
border-left:2px solid #ffffff;
border-bottom:2px solid #23272a;
border-right:2px solid #23272a;
width:208px;
margin-bottom:20px;
border-radius:10px;
}
.consumption span{
display:inline-block;
vertical-align:middle;
}
.consumption_label{
margin-bottom:5px;
font-size:22px;
font-family:Tahoma, Arial;
}
.consumption_value{
margin-right:5px;
width:120px;
height:33px;
font-size:26px;
font-family:Tahoma, Arial;
border-top:1px solid #ffffff;
border-left:1px solid #ffffff;
97
border-bottom:1px solid #23272a;
border-right:1px solid #23272a;
border-radius:6px;
background-color:#6e6e6e;
color:white;
text-align:right;
padding-right:5px;
}
.consumption_units{
width:auto;
height:32px;
font-size:25px;
font-family:Tahoma, Arial;
}
.consumption_container{
vertical-align:middle;
}
.label{
margin-bottom:5px;
font-size:20px;
font-family:Tahoma, Arial;
width:120px;
}
.line span{
98
display:inline-block;
}
.line{
margin-bottom:10px;
}
.label_value{
margin-right:5px;
width:80px;
height:33px;
font-size:26px;
font-family:Tahoma, Arial;
border-top:1px solid #ffffff;
border-left:1px solid #ffffff;
border-bottom:1px solid #23272a;
border-right:1px solid #23272a;
border-radius:6px;
background-color:#6e6e6e;
color:white;
text-align:right;
padding-right:5px;
}
.label_units{
width:auto;
height:32px;
font-size:25px;
font-family:Tahoma, Arial;
99
}
.electric_meter{
border-top:5px solid #23272a;
border-left:5px solid #23272a;
border-bottom:5px solid #23272a;
border-right:5px solid #23272a;
border-radius:5px;
padding:12px;
width:270px;
background-color:#dcdad6;
}
.device{
margin-bottom:5px;
font-size:18px;
font-family:Tahoma, Arial;
}
.device_label{
margin-right:10px;
}
.device span{
display:inline-block;
vertical-align:middle;
}
.devices_label{
100
margin-bottom:5px;
font-size:20px;
font-family:Tahoma, Arial;
font-weight:bold;
}
.device_state{
text-align:right;
float:right;
margin-top:2px;
}
.devices{
margin-top:15px;
width:305px;
}
.device_state_on{
color:green;
}
.device_state_off{
color:red;
}
</style>
<script>
var interval;
101
var Widget;
function WElectricMeter()
{
this.self = this;
this.getData = function(param, _callback)
{
var _url = 'getdata.php?widget=electric_meter&param=' +
param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
this.getDeviceData = function(deviceId, param, _callback)
{
var _url = 'getdata.php?widget=electric_meter&device=' +
deviceId + '&param=' + param;
$.getJSON(_url, {}, function(_data){
$.each(_data, function(key, val) {
if(key.toLowerCase() == 'value')
_callback(val);
});
}, 'html');
}
102
this.setVoltage = function(val)
{
$('.voltage_value').html(val);
}
this.setCurrent = function(val)
{
$('.current_value').html(val);
}
this.setPower = function(val)
{
$('.power_value').html(val);
}
this.setConsumption = function(val)
{
$('.consumption_value').html(val);
}
this.deviceGetState = function(deviceId)
{
var device = $('#device' + deviceId);
var state = device[0].state;
if(state == undefined || !state)
device[0].state = 0;
return state == undefined ? 0 : state;
}
103
this.deviceSetState = function(deviceId, state)
{
var device = $('#device' + deviceId);
switch(state)
{
case 1:
if(device.length)
{
device.find('.device_state_off').css('display','none');
device.find('.device_state_on').css('display','inline-block');
device[0].state = state;
}
break;
case 0:
if(device.length)
{
device.find('.device_state_on').css('display','none');
device.find('.device_state_off').css('display','inline-block');
device[0].state = state;
}
break;
default:
104
break;
}
}
var t = this;
this.getAllData = function()
{
t.getData('volt', function(val){
t.setVoltage(val);
});
t.getData('amp', function(val){
t.setCurrent(val);
});
t.getData('watt', function(val){
t.setPower(val);
});
t.getData('tar1', function(val){
t.setConsumption(val);
});
t.getDeviceData(17, 'active', function(val){
var state = parseInt(val);
if(t.deviceGetState(17) != state)
105
t.deviceSetState(17, state);
});
t.getDeviceData(18, 'active', function(val){
var state = parseInt(val);
if(t.deviceGetState(18) != state)
t.deviceSetState(18, state);
});
t.getDeviceData(19, 'active', function(val){
var state = parseInt(val);
if(t.deviceGetState(19) != state)
t.deviceSetState(19, state);
});
}
}
function electric_meter_getDataRecursive()
{
Widget.getAllData();
clearInterval(interval);
interval = setInterval(electric_meter_getDataRecursive, Math.floor(
2000 ) );
}
$(document).ready(function(){
106
Widget = new WElectricMeter();
electric_meter_getDataRecursive();
});
</script>
<div class="object_container">
<div class="electric_meter">
<div class="consumption">
<div class="consumption_label">Показания</div>
<div class="consumption_container">
<span class="consumption_value">00.00</span>
<span class="consumption_units">КВт*ч</span>
</div>
</div>
<div class="voltage">
<div class="voltage_container line">
<span class="voltage_label label">Напряжение</span>
<span class="voltage_value label_value">0</span>
<span class="voltage_units label_units">В</span>
</div>
</div>
<div class="current">
<div class="current_container line">
<span class="current_label label">Ток</span>
<span class="current_value label_value">0</span>
<span class="current_units label_units">А</span>
</div>
107
</div>
<div class="power">
<div class="power_container line">
<span class="power_label label">Мощность</span>
<span class="power_value label_value">0</span>
<span class="power_units label_units">Вт</span>
</div>
</div>
</div>
<div class="devices">
<div class="devices_label">Список приборов</div>
<div class="devices_list">
<div class="device" id="device17">
<span deviceid="17" class="device_label">Настольная
лампа</span>
<span class="device_state
device_state_off">ВЫКЛ</span>
<span class="device_state device_state_on"
style="display:none">ВКЛ</span>
</div>
<div class="device" id="device18">
<span deviceid="18" class="device_label">Лампа
накаливания</span>
<span class="device_state
device_state_off">ВЫКЛ</span>
<span class="device_state device_state_on"
style="display:none">ВКЛ</span>
108
</div>
<div class="device" id="device19">
<span deviceid="19"
class="device_label">Кофемолка</span>
<span class="device_state
device_state_off">ВЫКЛ</span>
<span class="device_state device_state_on"
style="display:none">ВКЛ</span>
</div>
</div>
</div>
</div>
109
110
Приложение 6. ZigBee-GSM шлюз. Разработка WiSeNet Lab
Принципиальная схема устройства
111
112
Топология печатной платы
Слои 1 и 2
113
Слои 3 и 4
114