Исходя из получившихся ценностей альтернатив наибольшую ценность имеет платформа ThingsBoard (=0,33), менее предпочтительной оказалась платформа MS Azure Iot Suite (=0,19), а наименее предпочтительными оказались платформы ThingWorx и IBM Watson IoT ( = 0,16).
Выводы по 2 главе
По итогам проведенного сравнительного анализа наибольшая ценность получилась у платформы ThingsBoard, и исходя из этого, моделирование будет выполняться на этой платформе.
Глава 3. Выбор протокола передачи данных
При исследовании интернета вещей нельзя проходить мимо программной части, а в частности протокола соединения, который играет ключевую роль в концепции интернета вещей. В данной главе будут рассмотрены такие протоколы как MQTT, HTTP, XMPP, так же будет проведен сравнительный анализ и определен протокол, который будет использоваться в разработке модели сбора данных.
3.1 Обзор существующих протоколов передачи данных для интернета вещей
HTTP(CoAP) [24]. Когда речь заходит о протоколе HTTP первое на что необходимо обратить внимание это на парадигму протокола. В основе протокола HTTP лежит парадигма запрос-ответ или request/response. HTTP пакет может состоять из трех частей: начальная строка, заголовок и непосредственно тело сообщения. И если последний пункт может отсутствовать (пакет с пустым телом сообщения), то первые два -- это обязательные составляющие HTTP-пакета.
В контексте интернета вещей используется протокол The Constrained Application Protocol (CoAP), который является вариацией протокола HTTP, но с UDP вместо TCP.
MQTT. Message Queue Telemetry Transport (MQTT) [25,26] - был стандартизирован только в 2013 году, хотя и был представлен компанией IBM в конце прошлого века, а именно в 1999 году. В основе протокола MQTT лежит парадигма издатель-подписчик или publish/subscribe. publish/subscribe. На рисунке 3 показан принцип работы протокола MQTT.
Рис. 3. Принцип работы протокола MQTT
Издатель (Publisher) - В концепции интернета вещей, чаще всего датчики или система датчиков, которые отправляют собранные данные брокеру, отличительной особенностью также является, отсутствие постоянного подключения к брокеру, так как краеугольным камнем для датчиков является энергоэффективность, поэтому продолжительное время они находятся в stand-by режиме.
Брокер (Broker) - отвечают за сбор, обработку (чаще всего связанную с отсеиванием ошибок) и отправку собранных данных подписчикам.
Подписчик (Subsriber) - Чаще всего программа, которая «подписана» на определенные данные у брокера от определенного издателя, которая обрабатывает полученные данные необходимым образом.
Также важно отметить, что существует вариация протокола MQTT, а именно Secure Message Queue Telemetry Transport (SMQTT), отличительной чертой которого, как можно догадаться из названия является шифрование.
XMPP. XMPP [27,28] - Extensible Messaging and Presence Protocol или сокращенно XMPP - Расширяемый протокол обмена сообщений и данных о присутствии. Формат сообщений - XML.
Отличается простой адресацией и работой с TCP. Широко применяется в приложениях, ориентированных на потребителя. Поддерживает различные модели, как например издатель-подписчик, запрос-ответ и другие. Протокол рассчитан на работу в среде без необходимости сбережения ресурсов, в ином случае лучше обратиться к другим протоколам.
3.2 Сравнительный анализ протоколов передачи данных для интернета вещей
В таблице 13 представлено сравнение протоколов передачи данных исходя из выделенных критериев:
ѕ назначение;
ѕ особенность;
Таблица 13.
Сравнение протоколов передачи данных
|
Протокол |
Назначение |
Особенность |
|
|
COAP |
Для сети с ограниченными ресурсами |
Учитывает различные вопросы при работе в сети с ограниченными ресурсами |
|
|
XMPP |
Для адресации в небольшой пользовательской сети |
Для идентификации используются простые идентификаторы |
|
|
MQTT |
Для загруженных сетей с большим количеством клиентов и брокером |
Использование очереди сообщений |
Выводы по 3 главе
Как видно из назначений протоколов, больше всего нам подходит протокол Message Queue Telemetry Transport (MQTT).
Глава 4. Теоретическая часть
4.1 Разработка модели
В данном разделе описывается предлагаемый подход к решению одной из поставленных задач (разработка модели сбора данных о дорожном покрытии) для достижения основных целей работы, а также описывается какие дополнительные сервисы необходимы для решения задачи.
4.1.1 Описание модели сбора данных
В данной выпускной квалификационной работе разрабатывается модель сбора данных о дорожном покрытии. В качестве протокола передачи данных ранее был выбран протокол MQTT, работающий поверх транспортного протокола TCP и по схеме Издатель - Подписчик. На рисунке 4 представлена схема разрабатываемой модели с использованием протокола MQTT.
Рис. 4 Концептуальная схема модели сбора данных о дорожном покрытии
В данном случае объекты ESP 1, ESP 2 являются системами курсовой устойчивости в каждом автомобиле. Когда ESP в автомобиле срабатывает, происходит информирование объектов Publisher 1 и Publisher 2 - мобильные устройства (телефоны, планшеты и т. д.), в зависимости от того какое устройство информируется. У мобильных устройств предполагается наличие включенного доступа в интернет и включенного GPS для повышения точности определения местоположения, однако, включение GPS не является обязательным атрибутом. Далее с помощью мобильного устройства происходит определение местоположения - широта и долгота, а затем происходит передача полученных данных на Broker (ThingsBoard) - платформу для моделирования решений в концепции интернета вещей. В настоящей реализации на данной платформе построено моделирование и здесь на панели мониторинга можно увидеть пришедшие данные - широту и долготу, а также установленную метку на Google картах. В качестве подписчика или Subscriber на данной схеме выступает любое приложение с картами, которое может подписаться на брокера и отображать данные у себя. Виджет с картой на панели мониторинга также является подписчиком.
В данной выпускной квалификационной работе разрабатываемая модель сбора данных должна иметь следующие возможности:
ѕ Отображение на карте нескольких меток с местоположениями срабатывания системы одного и нескольких устройств.
ѕ Отображение на карте меток с местоположением срабатывания, если расстояние между метками не менее 1 км от одного устройства.
ѕ Отображение на карте метки в том, случае, если произошло срабатывание как минимум двух устройств на том же месте для снижения количества ложных срабатываний.
Далее представлено краткое описание реализованного алгоритма для сбора данных, а схема архитектуры модели сбора данных представлена в приложении А. В качестве системы курсовой устойчивости используется специально разработанное в данной работе приложение - эмулятор ESP на Android:
1. На вход подаются данные авторизации - токен устройства, адрес сервера.
2. Проверка срабатывания системы ESP.
3. При положительном ответе информирование о срабатывании системы мобильного устройства. В эмуляторе происходит имитация данного процесса посредством переключателя.
4. Определение местоположения мобильным устройством.
5. Подключение мобильного устройства к брокеру с помощью инициализированных ранее данных для авторизации.
6. Запрос установления соединения.
7. При успешном соединении - информирование о подключении, в противном случае - запрос на установление соединения.
8. Запрос активности текущего соединения.
9. При успешном ответе - формирование сообщения с данными местоположения в формате JSON, в противном случае - запрос на установление соединения.
10. Передача сформированного сообщения на брокер.
11. Получение сформированного сообщения брокером на виртуальное устройство.
12. Отображение метки на карте панели мониторинга.
4.1.2 Подключение дополнительных сервисов
Для обеспечения корректной работы модели, в качестве дополнительных сервисов используется Google Maps API и Яндекс Облако, где создана виртуальная машина на ОС Ubuntu и развернут сервис ThingsBoard. Google Maps API используется для отображения google карт на виджете панели мониторинга модели.
Сервис ThingsBoard использует Java 8, поэтому так же на виртуальной машине установлен JDK 8 и настроена переменная окружения JAVA_HOME.
В качестве базы данных, на разворачиваемом сервисе используется встроенная база данных HSQLDB, так как данная модель является тестовой и не требует большого количества ресурсов. Для промышленных и готовых версий необходимо настраивать другие БД, например PostgreSQL или Cassandra DB.
Глава 5. Экспериментальная часть
5.1 Создание основы модели сбора данных
В настоящей выпускной квалификационной работе необходимо отразить срабатывание системы курсовой устойчивости автомобиля, передачу местоположение срабатывания на сервер и отображение местоположения на карте. Для того чтобы это реализовать необходимо подготовить виртуальное устройство ESP на платформе для интернета вещей ThingsBoard, подключить Google карты к платформе, получив API, создать виджет с картой, создать дашборд - панель для мониторинга, где будет отображаться карта с меткой о местоположении срабатывания системы.
5.1.1 Подготовка виртуального устройства ESP
Для начала работы необходимо на платформе ThingsBoard завести виртуальное устройство ESP. Для этого необходимо ввести название устройства, тип устройства. Название - ESP, тип устройства - esp (Рис.5).
Рис. 5. Создание виртуального устройства ESP
После того как устройство создано можно посмотреть его настройки - Подробности об устройстве (Рис.6).
Рис. 6. Подробности об устройстве
Главной частью в описании устройства является токен - ключ устройства, который в дальнейшем будет использоваться при получении геоданных. Посмотреть его можно нажать на кнопку «Управление учетными данными» (Рис.7). Для обеспечения безопасности Токен устройства закрыт.
Рис. 7. Учетные данные устройства
5.1.2 Создание и настройка виджета карты
Чтобы данные отображались на карте, необходимо использовать виджет с картами. На платформе ThingsBoard есть возможность выбрать один из существующих виджетов c картами, однако, такие виджеты не подходят, так как у них закрытый исходный код и нельзя модифицировать так, чтобы на карте отображалось несколько меток одновременно. Поэтому было принято решение создать собственный виджет с картой, на которой будут отображаться метки.
Для создания виджета нужно выбрать слева на панели «Галерея виджетов» и выбрать «создать новый набор виджетов» (Рис. 8)
Рис. 8. Создание набора виджетов
Далее нужно создать сам виджет. Для этого необходимо нажать «создать новый тип виджета» и выбрать необходимый тип виджета (Рис. 9.)
Рис. 9. Создание виджета с выборкой по времени
В результате создания виджета были использованы языки разметки HTML и CSS, а для реализации логики проставления метки на карту использовался javaScript. На рисунке 10 показан созданный виджет и его настройки.
Рис. 10. Созданный виджет и его настройки
5.1.3 Создание и настройка панели мониторинга
После того как создан виджет, необходимо его вывести на дашборд для мониторинга. Для этого на панели сбоку нужно перейти в «Дашборды» и выбрать «Добавить новый дашборд». Далее для создания дашборда достаточно ввести его название (Рис.11.)
Рис. 11. Добавление нового дашборда
Перед тем как добавлять созданный виджет требуется данный дашборд привязать к устройству.
Для этого нужно выбрать псевдонимы объекта добавить псевдоним, где выбрать ранее созданное виртуальное устройство ESP (Рис.12).
Рис. 12. Добавление псевдонима
Далее на созданный дашборд необходимо вынести созданный ранее виджет с картами. Для этого нужно выбрать «Добавить новый виджет». Отобразится окно с выбором виджетов и здесь нужно выбрать ранее созданный.
После того как виджет с картой добавился на дашборд необходимо произвести настройку проставления меток от передаваемых данных. Пример настройки показан на рисунке 13.
Рис. 13. Настройки виджета на дашборде
Для лучшего отражения полученных данных с устройства нужно добавить 2 виджета, отвечающие за телеметрию - с последними значениями и с историей (Рис.14).
Рис. 14. Виджеты с последней телеметрией и историей
5.2 Разработка приложения