razrabotka-modulya-sbora-i-peredachi-parametrov-injenernogo-oborudovaniya-umnogo-doma-na-osnove-tehnolo 112074

Пермский филиал федерального государственного автономного
образовательного учреждения высшего образования
«Национальный исследовательский университет
«Высшая школа экономики»
Факультет экономики, менеджмента и бизнес-информатики
Золотарева Екатерина Сергеевна
РАЗРАБОТКА МОДУЛЯ СБОРА И ПЕРЕДАЧИ ПАРАМЕТРОВ
ИНЖЕНЕРНОГО ОБОРУДОВАНИЯ УМНОГО ДОМА НА ОСНОВЕ
ТЕХНОЛОГИЙ ИНТЕРНЕТА ВЕЩЕЙ
Выпускная квалификационная работа
студента образовательной программы «Программная инженерия»
по направлению подготовки 09.03.04 Программная инженерия
Рецензент:
к.т.н,
доцент
кафедры
вычислительной математики,
механики и биомеханики
ФГБОУ ВО «ПНИПУ»
П.В. Максимов
Руководитель:
к.т.н,
доцент
кафедры
информационных технологий
в бизнесе НИУ ВШЭ – Пермь
__________________
А.В. Кычкин
Пермь, 2019 г.
Аннотация
В данной работе представлено описание разработки модуля сбора и передачи
параметров инженерного оборудования Умного дома на основе технологий Интернета
вещей. Данный модуль позволяет датчикам и устройствам Интернета вещей передавать
параметры их состояниях в базу данных временных рядов.
В первой главе описана предметная область «Умного дома» и «Интернета вещей»,
а также серверные технологии, используемый для реализации и проектирования. Вторая
глава содержит описание процесса проектирования модуля сбора и передачи параметров
инженерного оборудования Умного дома. Третья глава включает в себя описание
реализации сервера сбора данных с датчиков с помощью имеющихся технологий.
Работа включает в себя: 40 страницы основного текста, 27 иллюстраций, 7 таблиц,
одно приложение — техническое задание.
Библиографический список: 11 источников.
2
Оглавление
Введение ................................................................................................................................... 4
Глава 1. Анализ предметной области Интернета вещей ...................................................... 6
1.1. Описание предметной области ........................................................................... 6
1.2. Анализ существующих платформ для работы с Интернет вещами ............... 8
1.2.1. Платформа InfluxData ................................................................................... 8
1.2.2. Платформа ThingsBoard ............................................................................... 9
1.2.3. Платформа Tibbo AggreGate ...................................................................... 10
1.3. Инструменты для разработки модуля сбора данных ..................................... 12
1.3.1. Описание протоколов Интернета вещей .................................................. 12
1.3.2. Брокер сообщений MQTT Mosquitto ........................................................ 14
1.3.3. База данных временных рядов InfluxDB .................................................. 15
1.4. Описание существующего решений на базе платформы InfluxData ............ 16
Глава 2. Проектирование модуля сбора и передачи данных ............................................. 23
2.1. Требования к модулю сбора и передач параметров ....................................... 23
2.2. Диаграмма прецедентов .................................................................................... 25
2.3. Диаграмма активностей ..................................................................................... 28
2.4. Диаграммы последовательностей .................................................................... 29
2.5. Диаграмма классов............................................................................................. 30
2.6. Диаграмма компонентов ................................................................................... 32
2.7. Диаграмма развертывания ................................................................................ 33
Глава 3. Программная реализация модуля сбора данных.................................................. 34
3.1. Системная архитектура ..................................................................................... 34
3.2. Разработка модуля сбора данных ..................................................................... 36
Заключение ............................................................................................................................. 40
Библиографический список .................................................................................................. 41
Приложение. Техническое задание ...................................................................................... 43
3
Введение
С каждым днем стремительно развиваются передовые технологические системы,
позволяющие автоматизировать бытовые задачи. Сегодня многие люди используют
различные бытовые приборы и устройства, которые являются частью системы
Умный Дом. Данная система обеспечивает связь между бытовыми приборами и
пользователями, а также расширяет возможности автоматизации, мониторинга и
дистанционного управления девайсами. Например, когда усталый и голодный человек
возвращается домой после тяжелого рабочего дня, его машина сообщает об этом
устройствам в его доме, некоторые из них начинают работать: включается чайник,
термостат регулирует комфортную температуру и в микроволновке разогревается ужин.
На данный момент существует множество веб-систем и мобильных приложений
для работы с Интернет вещами. На сегодняшний день наиболее современными и
высокотехнологичными платформами для управления интернет вещами являются —
Amazon Web Services IoT Core, Tibbo AggreGate, ThingsBoard, Blynk, InfluxData, Ayla
Networks, PTC Thingworx, IBM IoT Foundation, DeviceHive, Home Assistant, Sierra
Wireless, Intel IoT, Google Brillo.
Объектом исследования данной работы является инженерное оборудование
Умного дома, предметом исследования — средства сбора и передачи параметров
инженерного оборудования Умного дома на основе технологий Интернета вещей.
Цель работы: разработать модуль, осуществляющий сбор и передачу параметров
между устройствами Интернета вещей и базой данных временных рядов.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Исследовать инженерное оборудование Умного дома и рассмотреть
существующие системы.
2. Изучить инструменты для разработки модуля сбора данных.
3. Составить требования для проектирования и разработки модуля сбора и
передачи параметров инженерного оборудования Умного дома на основе
протокола MQTT Интернета вещей.
4. Спроектировать модуль сбора и передачи данных с устройств Умного дома в
базу данных временных рядов.
5. Разработать модуль и провести его тестирование.
4
Концепция Интернета вещей базируется на принципе межмашинного общения:
без вмешательства человека электронные устройства «общаются» между собой.
Интернет вещей — это автоматизация, но более высокого уровня. В отличие
от «умных» домов узлы системы используют TCP/IP-протоколы для обмена данными
через каналы глобальной сети Интернет. В статье «Архитектура сетевого управляющего
комплекса здания на базе IoT-устройств» [1] авторами рассматривается задача
проектирования киберфизической системы, применяемой в качестве сервиса для
управления интеллектуальными зданиями с использованием технологий Интернета
вещей.
При написании данной работы будут использованы следующие методы
исследования: анализ имеющихся платформ для оборудования Умного Дома для
формирования
требований,
объектно-ориентированный
анализ
и
объектно-
ориентированное проектирование при разработке архитектуры модуля.
Научная новизна данной работы заключается в том, что модуль сбора и передачи
данных
инженерного
оборудования
«Умный
дом»
будет
автоматически
идентифицировать устройства, распределять подписки на топики, обращаться к
параметрам по топикам на основе конфигураций. Данный модуль будет работать в
пределах данной системы, и выполнять функции по идентификации подключаемых
устройств, оформлению подписок, назначению топиков, взаимодействию с брокером
сообщений, БД и приложению пользователя.
Практическая значимость работы заключается в возможности использования
разработанной системы при управлении зданием, в том числе освещением, климатом,
доступом, водоснабжении и электроснабжении. Данная информационная система будет
позволять выполнять автоматизированный сбор состояний устройств, а также значений
параметров окружающей среды, данных с датчиков и передавать всю информацию в
базу данных.
Первая глава работы будет содержать описание существующих решений, далее на
основе анализа имеющихся систем будут составлены технические характеристики к
разрабатываемому модулю передачи и сбора параметров. Во второй главе будет описана
архитектура разрабатываемого модуля, будут представлены диаграммы прецедентов,
активности, последовательности, развертывания и компонентов. Третья глава будет
содержать реализацию модуля сбора и передачи данных и его тестирование.
5
Глава 1. Анализ предметной области Интернета вещей
В первой главе будет рассмотрено общее понятие технологий «Умный дом» и
«Интернет вещей», их концепция и назначение. Данная глава будет содержать описание
существующих интеграционных платформ для Интернета вещей, будет рассмотрена их
архитектура. В данной главе будет представлено описание используемых алгоритмов и
методов, необходимых для реализации системы, а также выполнен обзор технологий,
используемых при проектировании модуля сбора данных.
1.1.
Описание предметной области
Умный дом - это набор технологий, которые позволят пользователям тратить
меньше времени на домашние дела, независимо настраивая систему домашней
безопасности и создавая единую сеть для управления бытовой техникой с помощью
смартфона. Интернет вещей - это сеть физических объектов, подключенных к Интернету
и способных идентифицировать себя с другими устройствами. Хорошо продуманное
приложение «Интернет вещей» может снизить потребление энергии, повысить
безопасность в зданиях и в городе или повысить комфортность в здании [2].
В развитых странах Умный дом пересекается с концепцией экологичности и
устойчивости, поскольку данная технология помогает рационально использовать
ограниченные природные ресурсы,
минимально негативно воздействовать на
окружающую среду и благосостояние людей. Основная задача Умного дома - повысить
комфорт жильцов и облегчить повседневную жизнь [3].
Интернет вещей дает организациям абсолютно новые способы управления и
мониторинга
контролировать
удаленно
удаленно
выполняемых
операций.
расположенные
объекты
Он
позволяет
полностью
и
постоянно
поставляет
информацию приложениям и в хранилища данных.
Интеллектуальная система управления домом объединяет отдельные подсистемы
и устройства в единый комплекс. Модуль сбора данных для инженерного оборудования
Умного дома является необходимой частью всей платформы для всей платформы для
управления Интернетом и передачи информации на экран пользовательского
приложения. Эта технология обеспечивает связь между устройствами Internet of Things
с использованием Wi-Fi, что позволяет устройствам передавать данные об их статусе в
базу данных.
6
Рассмотрим примерную архитектуру Умного Дома (рис. 1.1). При разработке
системы удаленного управления обычно выделяют следующе основные компоненты:
приложения для пользователя, веб-сервер, сервер Умного Дома, а также контроллер для
управления датчиками и сенсорами.
Файлы скриптов и
сценариев
Apache
СУБД
JavaScript +
JQuery
Back-end App
Front-end App
Контроллер сети
Приложение
Виджет
Ethernet/Wi-Fi
Контроллер
Реле
Контроллер
Датчики
температуры
Контроллер
Датчики
движения
Кнопки
Контроллер
Двигатели
Датчики
протечки
Рисунок 1.1. Структура технологий Умного Дома
Мобильное приложение или веб-браузер необходимы для удаленного управления
устройствами Умного дома. С помощью данного компонента осуществляется передача
команд на облачные сервер, а также получение оттуда информации о состоянии
датчиков.
Веб-сервер предназначен для хранения данных о состоянии датчиков и устройств
в БД. Он выступает также в качестве посредника между удаленными устройствами
управления и сервером Умного Дома. Данная функция осуществляется путем передачи
команд, например, с мобильных устройств в облако, где они обрабатываются и
передаются дальше на домашний сервер.
7
Сервер Умного Дома предназначен для получения команд от веб-сервера и их
дальнейшей передачи на контроллеры, а также передачи в обратном порядке данных с
датчиков, поступающих на контроллер.
Контроллер управляет подключенными датчиками, принимает команды с сервера
и отправляет ему информацию об изменении состояния датчика. На центральном
контроллере регистрируются все имеющиеся устройства, а он уже обеспечивает и вебинтерфейс, и сценарии, и передачу команд между устройствами.
Контроллер иногда называют «мозгом» Умного дома, так как данный прибор
контролирует работу сети и всех входящих в нее устройств, хранит в своей памяти
сложные сценарии, определенные наборы действий, которые прописаны пользователем,
а также данный механизм обеспечивает связь системы с смартфоном, планшетом или
компьютером. Различные датчики, определяющие движения, температуру, влажность, –
это так называемые «органы чувств» Умного дома. С их помощью система непрерывно
получает информацию о том, что происходит в доме.
В целях эффективной работы системы Умный Дом необходимо обеспечить
надежное взаимодействие между облаком и домашним сервером, а также между
удаленными устройствами управления и облаком. Одним из популярных открытых
протоколов связи для Умного дома является MQTT. MQTT требует наличие сервера брокера, который объединяет подключенные устройства в сеть. Сами же устройства при
подключении подписываются на топики в которых отсылаются данные и брокер
отсылает только те топики устройству, которые ему нужны.
1.2.
Анализ существующих платформ для работы с Интернет вещами
1.2.1. Платформа InfluxData
InfluxData -
платформа
для
сбора,
хранения,
визуализации
и
управления временными рядами [4]. База данных InfluxDB является ядром платформы,
все остальные части взаимодействуют через базу данных. InfluxDB - это кластеризуемая
база данных, предназначенная для хранения временных рядов, метрик.
Основные возможности InfluxDB:
1. SQL подобный язык запросов InfluxQL.
2. HTTP(S) API для записи и выборки данных.
3. Возможность сохранять миллиарды точек измерений.
8
4. Поддержка политик хранения данных.
Telegraf - это агент сбора данных, который собирает данные из растущего списка
источников и переводит их в формат данных Line Protocol для хранения в InfluxDB. Эта
«подключаемая» расширяемая архитектура позволяет легко создавать подключаемые
модули, которые одновременно извлекают и передают данные из различных источников
и конечных точек и обратно.
Chronograf - это административный пользовательский интерфейс и механизм
визуализации платформы.
InfluxDB - это база данных временных рядов, созданная с нуля для обработки
высоких нагрузок записи и запросов.
Kapacitor - это встроенный механизм обработки данных. Он может обрабатывать
как потоковые, так и пакетные данные из InfluxDB.
Архитектура системы InfluxData представлена на рис. 1.2.
Пользователь
Статистика
Chronograf
Запрос
База данных
Telegraf
Приложение
MQTT
Результат
InfluxDB
Kapacitor
Устройство
Рисунок 1.2. Архитектура платформы InfluxData
1.2.2. Платформа ThingsBoard
ThingsBoard - это платформа IoT с открытым исходным кодом для сбора,
обработки, визуализации и управления устройствами.
Данная технология обеспечивает подключение устройств через стандартные
протоколы IoT – MQTT, HTTP и поддерживает как облачные, так и локальные
9
развертывания.
ThingsBoard
(рис.
1.3)
сочетает
в
себе
масштабируемость,
отказоустойчивость и производительность, поэтому пользователь никогда не потеряете
свои данные [5]. ThingsBoard позволяет настраивать информационные панели для IoT
устройств. Каждая панель мониторинга IoT может содержать несколько виджетов
панели мониторинга, которые визуализируют данные с нескольких устройств IoT.
ThingsBoard IoT Gateway - это решение с открытым исходным кодом, которое
позволяет интегрировать устройства IoT, подключенные к устаревшим и сторонним
системам, с ThingsBoard.
ThingsBoard IoT Gateway предоставляет следующие функции:
1. Расширение MQTT для управления, настройки и сбора данных с устройств
IoT, подключенных к внешним брокерам MQTT с использованием
существующих протоколов.
2. Расширение OPC-UA для сбора данных с устройств IoT, подключенных к
серверам OPC-UA.
3. Расширение Sigfox для сбора данных с устройств IoT, подключенных к Sigfox
Backend.
4. Постоянство собранных данных, чтобы гарантировать доставку данных в
случае сбоев сети и оборудования.
5. Автоматическое переподключение к кластеру ThingsBoard.
Real Time
Dashboards
Приложение
пользователя
Пользователь
OPC-UA
IoT-шлюз
Gateway core
БД
MQTT
Серверное
Приложение
Устройство
Рисунок 1.3. Архитектура платформы ThingsBoard
1.2.3. Платформа Tibbo AggreGate
Tibbo AggreGate – российская интеграционная платформа для Интернета вещей,
созданная компанией «Tibbo Systems», используется для мониторинга и управления
10
различными аппаратными устройствами. Интеграционная платформа для Интернета
вещей AggreGate обеспечивает сбор, хранение, обработку и визуализацию данных M2M
устройств, а также интеграцию этих данных с системами предприятия. В отличие от
других решений, имеющих базовую инфраструктуру и комплект разработчика ПО для
расширения
возможностей
вертикальных
приложений,
AggreGate
(рис.
1.4)
представляет из себя комплексную платформу, имеющую средства визуальной
разработки пользовательских интерфейсов и обработки событий на стороне сервера [6].
БД
MQTT
Tibbo Aggregate
Сервер
Агент
Устройство
Единая консоль
Пользователь
Рисунок 1.4. Архитектура платформы Tibbo AggreGate
Сервер – Java-приложение, обеспечивающее коммуникации с устройствами,
хранение данных и их автоматизированную обработку. Сервера могут объединяться в
кластер для обеспечения высокой доступности и поддерживать пиринговые отношения
друг с другом в распределенных инсталляциях. Сервер AggreGate управляет встроенным
веб-сервером, обеспечивающим поддержку веб-интерфейсов. Сервер заведует чтением
данных
из
устройств
и
записью
изменений,
этот
процесс
называется
двухсторонней синхронизацией. На стороне сервера создается снимок устройства,
содержащий копии последних значений метрик устройства и изменения, произведенные
операторами и системными модулями и не записанные в устройство из-за отсутствия
связи. Изменения конфигурации доставляются в устройства по принципу первой
возможности, позволяя производить групповые изменения конфигурации устройств, не
дожидаясь их одновременного появления онлайн.
Единая консоль – кросс-платформенное клиентское ПО, обеспечивающее
одновременную работу с одним или несколькими серверами в режиме администратора,
системного инженера или оператора.
11
Агент – библиотека, которая может быть внедрена в микропрограмму IoT
устройства с целью обеспечения коммуникаций с серверами, унификации настройки
устройства, выполнения операций с ним, и асинхронной отправки событий.
Можно сделать вывод о том, что каждая из вышеперечисленных платформ
предоставляет широкие возможности для разработчиков и широкий спектр доступных
устройств для пользователей. IoT платформы InfluxData, Tibbo AggreGate и ThingsBoard
поддерживают аналитику в реальном времени, имеют возможность визуализации
данных, обеспечивают безопасную передачу данных. Каждая из платформ имеет
отдельный модуль для автоматизированного сбора данных и для записи информации в
БД. У платформы InfluxData это – агент Telegraf, у платформы ThingsBoard за сбор
данных отвечает ThingsBoard IoT Gateway, а платформа Tibbo AggreGate также имеет
отдельный сервер беспечивающий коммуникации с устройствами и хранение данных.
Среди протоколов, используемых платформами IoT, наиболее популярными являются
MQTT, HTTP/HTTPS.
1.3.
Инструменты для разработки модуля сбора данных
1.3.1. Описание протоколов Интернета вещей
Протоколы передачи данных IoT – правила, определяющие способы обмена
данными между объектами сети Интернета вещей.
Процессы сетевого взаимодействия происходят на множестве уровней и могут
быть сложны для понимания. Эталонная модель взаимодействия открытых систем
представляет собой абстрактную модель взаимодействия компьютеров, приложений и
других устройств в сети. Каждый компьютер в сети использует набор протоколов для
выполнения функций, назначенных каждому уровню. Совокупность протокол
называется стеком протоколов. На вершине стека находится пользовательское
приложение, которое делает запросы к ресурсам, расположенным в сети. Внизу стека
располагается среда передачи данных, объединяющая компьютеры в есть на физическом
уровне.
Модель OSI описывает правила и процедуры передачи данных в различных
сетевых средах при организации сеанса связи. Основными элементами модели являются
уровни, прикладные процессы и физические средства соединения. На рис. 1.5
представлена структура базовой модели.
12
Уровни:
Пользователи
Интерфейс
пользователя
Прикладные процессы
Прикладной
интерфейс
7.
Прикладной
6.
Представительский
5.
Сеансовый
4.
Транспортный
3.
Сетевой
2.
Канальный
1.
Физический
Область
взаимодействия
открытых
систем
Физические средства соединения
Рисунок 1.5. Архитектура модели OSI
Эталонная модель OSI состоит из 7 уровней, причем принято начинать отсчёт с
нижнего:
1. Физический
уровень
(physical
layer)
-
самый
нижний
уровень,
непосредственно осуществляющий передачу потока данных.
2. Канальный уровень (data link layer) - уровень реализует запросы сетевого
уровня и использует физический уровень для приема и передачи.
3. Сетевой уровень (network layer) - этот уровень определяет путь, по которому
данные будут переданы.
4. Транспортный уровень (transport layer) - этот уровень обеспечивает
надёжность передачи данных от отправителя к получателю.
5. Сеансовый уровень (session layer) - На этом уровне происходит организация
сеансов обмена информацией между оконечными машинами
6. Представительский уровень или уровень представления (presentation layer) данный преобразует данные в соответствующий формат.
7. Прикладной уровень (application layer) – это самый верхний уровень модели.
Он осуществляет связь пользовательских приложений с сетью.
13
1.3.2. Брокер сообщений MQTT Mosquitto
Протоколы передачи данных IoT – правила, определяющие способы обмена
данными между объектами сети Интернета вещей.
Для обмена информацией устройствам нужен простой и легковесный сетевой
протокол, который позволит им эффективно функционировать и взаимодействовать в
сети, асинхронность, а также поддерживаемый любыми устройствами и операционными
системами [7]. Все эти задачи с легкостью решает протокол MQTT.
MQTT или Message Queueing Telemetry Transport осуществляет сбор данных от
множества узлов и передачу на сервер. Основывается на модели издатель-подписчик с
использованием промежуточного сервера – брокера. В качестве транспорта – TCP.
Протокол MQTT требует обязательного наличия брокера данных. Это
центральная идея технологии. Все устройства посылают данные только брокеру и
принимают данные тоже только от него. Брокер — это программа, выполняющая
функции TCP сервера с динамической базой данных [8].
Протокол создавался, чтобы обеспечить открытость, простоту, минимальные
требования к ресурсам и удобство внедрения. MQTT располагается поверх TCP/IP и
работает с моделью «клиент/сервер», где каждый датчик является клиентом и
подключен к серверу, который является брокером. Протокол MQTT требует
обязательного
наличия
брокера,
который
управляет
распределением
данных
подписчикам. Все устройства или актуаторы посылают данные только брокеру и
принимают данные тоже только от него.
В сети на базе протокола MQTT различают следующие объекты:
1. Издатель
(Publisher)
–
MQTT-клиент,
который
при
возникновении
определенного события передает брокеру информацию о нём, публикуя
соответствующие топики.
2. Брокер (Broker) – MQTT-сервер, который принимает информацию от
издателей и передает ее соответствующим подписчикам, в сложных системах
может выполнять также различные операции, связанные с анализом и
обработкой поступивших данных. Разные брокеры могут соединяться между
собой, если они подписываются на сообщения друг друга.
14
3. Подписчик (Subscriber) – MQTT-клиент, который после подписки к брокеру
большую часть времени «слушает» его и постоянно готов к приему и
обработке входящего сообщения на интересующие топики от брокера.
Схема простого взаимодействия между подписчиком, издателем и брокером
представлена на рисунке 1.6.
Устройство
1
Устройство
2
MQTT-broker
Publish
Устройство
3
Устройство
4
Рисунок 1.6. Основная структура работы MQTT брокера
Датчики температуры являются «издателями», так как они могут только
передавать параметры о своем состоянии и не могут принимать никакие управляющие
команды. Компьютер является «подписчиком», поскольку он принимает данные с
MQTT брокера о состоянии датчиков.
Существует расширение для Google Chrome, которое называется MQTT Lens. Оно
позволяет подключается к брокеру MQTT и может подписываться, и публиковать темы
с MQTT брокера.
1.3.3. База данных временных рядов InfluxDB
Временные ряды – один из наиболее часто встречающихся в аналитической
практике объектов. Временной ряд – это статистика серии наблюдений за одним и тем
же явлением, параметром какого-либо процесса, на протяжении некоторого времени.
Каждому результату измерения соответствует определенное время, когда это изерение
было сделано, или его порядковый номер по шкале времени.
InfluxD кластеризуемая база данных, специально разработанная для хранения
временных рядов и метрик. InfluxDB полностью написан на Go и компилируется в один
15
двоичный файл без внешних зависимостей. Он предоставляет возможности для
пользователя выполнять запись данных и отправлять запросы в БД к через командную
строку [9].
В числе преимуществ InfluxDB в первую очередь нужно выделить следующие:
 отсутствие зависимостей;
 возможность работы в кластерном режиме;
 возможность сохранять миллиарды точек измерений;
 классификация данных по тегам для быстрой и эффективной выборки;
 наличие библиотек для большого числа языков программирования.
 SQL-подобный язык запросов, с помощью которого можно производить
различные операции с временными рядами.
InfluxDB предназначена для хранения метрик DevOps мониторинга, данных от
датчиков сенсоров (sensor data), данных для on-line аналитики временных рядов.
Линейный протокол InfluxDB - это текстовый формат для записи точек в базу
данных. Одна строка Line Protocol представляет одну точку данных в InfluxDB. Он
информирует InfluxDB об измерении точки, наборе тегов, наборе полей и отметке
времени.
1.4.
Описание существующего решений на базе платформы InfluxData
Данная
часть
будет
содержать
описание установки и
настройки связки
технологий, позволяющих быстро и достаточно просто получить работающий сервис
мониторинга.
Сначала рассмотрим основные понятия:
1. Контроллер Умного дома – это устройство, которое реализует сбор
измерительной информации, их обработку и формирование команд управления
набором умных вещей по сценариям, а также формирует отчет о состоянии
Умного дома.
2. Устройство умного дома – это прибор, состоящий из контроллера, датчика
и бытового прибора, например, холодильника, термометра, жалюзи.
3. Датчик – средство измерений, предназначенное для выработки сигнала
измерительной информации в форме, удобной и понятной для передачи,
дальнейшего преобразования, обработки и (или) хранения в системе управления.
16
4. Показатели датчика – характеристики, которые датчик может считывать и
отправлять (напр. Температура, освещенность и пр.).
5. Актуаторы — исполнительные устройства, непосредственно исполняющие
команды. Это самая многочисленная группа, в которую входят умные
выключатели, умные розетки, сирены, климат-контроллеры и так далее.
При подключении сервиса мониторинга были использованы следующие
программы:
1. MQTT Mosquitto – брокер, предназначенный для сбора данных с интернет
вещей.
2. MQTT Lens – расширение для Google Chrome, для визуального представления
работы MQTT Mosquitto.
3. Telegraf – утилита для сбора измерений временных рядов [10].
4. InfluxDB – кластеризуемая база данных, специально разработанная для
хранения временных рядов.
5. Grafana – инструмент для визуализации временных рядов.
Сначала была выполнена установка брокера MQTT Mosquitto [11]. Установка
была выполнена успешно, и работа MQTT Mosquitto Broker отображается в Службах
Windows (рис. 2.7).
Рисунок 2.7. Службы Windows
Подключение брокера сообщений MQTT Mosquitto было выполнено успешно, его
работа была отображены в расширении MQTT Lens (рис. 2.8).
17
Рисунок 2.8. MQTT Lens
На рис. 2.9 мы можем увидеть данные о датчике № 4: название теста, топик, по
которому идет передача данных через брокер сообщений MQTT, время и значение
температуры.
Рисунок 2.9. Датчик в MQTT Lens
18
Далее были установлены база данных InfluxDB (рис. 2.10) и агент для сбора
данных Telegraf (рис. 2.11).
Рисунок 2.10. База данных InfluxDB
При подключении Telegraf к InfluxDB автоматически создалась база данных
«telegraf», в которую записывались все данных с четырех датчиков, измеряющих
температуру.
Рисунок 2.11. Telegraf
Команда «show databases» показывает список всех имеющихся БД в InfluxDB.
Большинство запросов в InfluxDB выполняется в рамках какой-либо выбранной базы
данных. Далее была выбрана необходимая БД с помощью команды «use telegraf». Для
просмотра имеющихся измерений в БД была введена команда «show measurements».
19
Данные в InfluxDB организованы в виде временного ряда, который содержит
измеренные значения. Если провести аналогию с SQL базой данных, то измерение
(measurement) - это таблица, в которой первичным ключом является колонка со
временем (timestamp). Теги (tags) - это индексированные колонки, а поля (fields) - это не
индексированные колонки. Только в отличие от SQL базы данных в InfluxDB, можно
сохранить миллионы измерений (measurement), вы не обязаны заранее определять
схему, и null значения не будут храниться.
На рис. 2.12 отображена часть списка с данными, хранящимися в нашей БД,
которые содержат значение температуры подключенных датчиков.
Рисунок 2.12. InfluxDB
Минус используемой утилиты для сбора данных Telegraf состоит в том, что
данный формат данных является неудобным. Необходимо решить проблему обработки
данных и обезличенности:
1. Пользователю непонятно откуда берутся «temperature1», «temperature2»,
«temperature3», «temperature4».
2. С какого устройства поступают параметры.
3. К каким контроллерам привязаны данные параметры с датчиков.
4. В каком помещении находится данный датчик.
20
Для решения данной проблемы необходимо создать модуль сбора данных,
который будет преобразовывать полученную информацию в удобный формат для
обработки данных.
Для выборки данных, был использовать SQL подобный язык запросов InfluxQL
«select * from mqtt_consumer». InfluxDB устанавливает автоматически текущее время
сервера для каждой вставленной точки.
Завершающим шагом являлась установка Grafana. Для запуска Grafana
необходимо открыть браузер и ввести адрес http://localhost:8080/, открывается окно:
Рисунок 2.13. Запуск Grafana
При авторизации были использованы стандартные логин и пароль: admin / admin.
Сначала был выбран источник данных (datasources - add datasource) БД telegraf.
Далее был создан дашборд для визуализации, мониторинга и анализа данных. Был
сконструирован запрос, используя подсказки интерфейса. На рисунке 2.14 отображен
дашборд, который отображает определенные показатели в течение установленного
периода времени.
Grafana представляет собой удобный дашборд для выборки и визуализации
метрик.
21
Рисунок 2.14. Созданный dashboard в Grafana
Так работает мониторинг данных с помощью подсистем платформы InfluxData.
Telegraf позволяет передавать в БД большое количество метрик в необработанном виде,
что неудобно для дальнейшей работы над данными.
22
Глава 2. Проектирование модуля сбора и передачи данных с
устройств Интернета вещей
Третья глава будет содержать требования к разрабатываемой системе. А также в
данной главе будет выполнено построение математической модели, описывающей
решаемую проблему, будут реализованы диаграммы, описывающие концепцию работы
реализуемого модуля.
2.1.
Требования к модулю сбора и передач параметров
Рисунок 2.1 отображает схему работы имеющегося сервера сбора данных с
помощью серверного агента для сбора данных Telegraf.
Контроллер
MQTT
Брокер
Telegraf
Influx DB
Grafana
Рисунок 2.1. Модель AS IS
На основе анализа аналогов интеграционных платформ для Умного дома, а также
различных средств и технологий, используемых для взаимодействия с Интернет
вещами, были сформулированы требования для проектирования и разработки модуля
сбора данных (рис. 2.2).
Контроллер
MQTT
Брокер
Telegraf
Influx DB
Grafana
C# App
Модуль сбора
данных
ID контроллера
MS SQL
Рисунок 2.2. Модель AS TO BE
Необходимо разработать модуль, осуществляющий сбор и передачу параметров с
контроллеров в таблицу в InfluxDB, в которую будут складывать под правильными
23
названиями
фактические
значения
с
контроллеров
и
соответствующие
им
характеристики, хранящиеся в другой БД. Структура датчиков и контроллеров с их
характеристиками хранится в БД Microsoft SQL, которая была разработана в рамках
группового проекта при реализации Менеджера сценариев.
Функциональные требования к программному обеспечению — это совокупность
утверждений, характеризующих поведение системы.
Были выявлены следующие функциональные требования:
1. Предоставлять пользователю выбор датчика из БД.
2. Сбор параметров с MQTT брокера.
3. Замена названий измерений в TOPIC на данные из базы данных Microsoft SQL.
4. Запись данных в СУБД InfluxDB.
5. Визуальное представление параметров из InfluxDB.
В отличии от функциональных требований нефункциональные определяют
характер поведения системы, в том числе бизнес-правила, системные требования и
ограничения.
Нефункциональные требования:
1. Система должна быть реализована на языке С# в среде Visual Studio.
2. База данных с характеристиками и названиями датчиков должна быть
реализована с помощью MS SQL Server.
3. База данных для записи параметров должна быть реализована с помощью
СУБД InfluxDB.
4. Сбор данных с датчиков должен быть осуществлен с помощью MQTT
брокера.
5. Визуализация данных должна быть реализована с помощью сервиса Grafana.
В базе данных MSSQL должна храниться информация:
1. О здании: код здания, название, адрес.
2. О помещении: код помещения, название.
3. Об устройстве: код устройства, название.
4. О контроллере: код контроллера, название.
5. О настройках контроллера: код настройки, название, значение.
6. О состоянии контроллера: код состояния, название, значение.
7. О переменных контроллера: код переменной, название, значение.
24
8. О входящих переменных: код переменной, номер.
9. О датчике: код датчика, тип, минимальное значение, максимальное значение.
10. О исходящих переменных: код переменной, номер.
11. Об актуаторе: код актуатора, тип, минимальное значение, максимальное
значение.
2.2.
Диаграмма прецедентов
Запуск сбора
данных
<<включить>>
Выбор датчика
Сбор данных
Регистрация
контроллера
<<включить>>
Тестирование
связи
Пользователь
<<включить>>
Настройка связи
<<включить>>
Редактирование
настроек
Передача данных
Контроллер
MQTT брокер
<<включить>>
Измерение
состояния
Датчик
Рисунок 2.3. Диаграмма прецедентов
Диаграмма прецедентов, представленная на рисунке 2.3, описывает ситуации,
когда главный пользователь, датчик, контроллер и MQTT брокер взаимодействует друг
с другом.
25
Акторами являются Пользователь, Датчик, Контроллер и MQTT брокер.
1. Название: Запуск сбора данных.
Акторы: Пользователь.
Краткое описание: Пользователь запускает сбор данных с датчиков в БД.
Триггер: Пользователь хочет запустить модуль.
Основной поток: см. табл. 2.1.
Таблица 2.1. Прецедент «Запуск сбора данных»
Действия акторов
Отклик системы
1. Открыть приложение в Visual Studio.
2. Нажать запуск модуля сбора данных.
3. Сбор данных с MQTT брокера и запись
данных в InfluxDB.
2. Название: Сбор данных.
Акторы: MQTT брокер.
Предусловия: Запуск модуля сбора данных.
Краткое описание: MQTT брокер получает параметры с контроллера и передает
в модуль сбора данных.
Триггер: MQTT брокеру необходимо передать данные с контроллера в консольное
приложение.
Основной поток: табл. 2.2.
Таблица 2.2. Прецедент «Сбор данных»
Действия акторов
1. Запуск службы брокера.
Отклик системы
2. Подключение модуля к MQTT брокеру и
запрос данных.
3. Получение данных с контроллера.
4. Отображение данных в MQTT Lens.
3. Название: Выбор датчика.
Акторы: Пользователь.
Краткое описание: Пользователь выбирает из списка необходимый датчик.
Триггер: Пользователь хочет просмотреть данные о датчике определенного
устройства.
Основной поток: см. табл. 2.3.
26
Таблица 2.3. Прецедент «Выбор датчика»
Действия акторов
Отклик системы
1. Открыть приложение в Visual Studio.
2. Выбрать из списка здание, помещение,
устройство и контроллер.
3. Нажать кнопку «Просмотр».
4. Сделать выборку из БД.
4. Название: Передача данных.
Акторы: MQTT брокер, Контроллер.
Краткое описание: MQTT брокер и Контроллер передают параметры с датчика.
Триггер: MQTT брокеру и Контроллеру необходимо отправить полученные
данные.
Основной поток: табл. 2.4.
Таблица 2.4. Прецедент «Передача данных»
Действия акторов
Отклик системы
1. Получение данных контроллером с
датчик.
2. Передача
данных
контроллером
3. Запрос данных с брокера.
брокеру.
4. Передача
данных
брокером
в
5. Обработка данных.
консольное приложение.
5. Название: Регистрация контроллера.
Акторы: Пользователь.
Краткое описание: Пользователь добавляет регистрирует новый котроллер.
Триггер: Пользователю необходимо добавить и зарегистрировать новый
контроллер.
Основной поток: табл. 2.5.
Таблица 2.5. Прецедент «Регистрация контроллера»
Действия акторов
Отклик системы
1. Настройка нового контроллера.
2. Заполнение информации о контроллере.
3. Добавление нового контроллера в БД.
6. Название: Настройка связи.
Акторы: Пользователь.
27
Краткое описание: Пользователь настраивает связь с контроллером для
получения данных с датчиков.
Триггер: Пользователю необходимо настроить связь для сбора данных.
Предусловие: Пользователь запускает систему.
Основной поток: табл. 2.6.
Таблица 2.6. Прецедент «Настройка связи»
Действия акторов
Отклик системы
1. Открыть модуль сбора данных.
2. Прописать настройки для контроллера и
3. Сохранить настройки.
связи с ним.
7. Название: Измерение состояния.
Акторы: Датчик.
Краткое описание: Датчик измеряет показатели своего состояния.
Триггер: Датчику необходимо измерить параметры своего состояния для передчи
их контроллеру.
Основной поток: табл. 2.7.
Таблица 2.7. Прецедент «Измерение состояния»
Действия акторов
Отклик системы
1. Включение датчика.
2. Измерение состояния.
3. Запись данных в БД.
2.3.
Диаграмма активностей
Для описания процессов предметной области модуля сбора данных были выбрана
диаграммы
активностей
языка
UML,
которые
позволяют
понять
контекст
возникновения прецедентов. Данная диаграмма представляет собой некую блок-схему,
которая наглядно показывает, как поток управления переходит от одной деятельности к
другой.
Прецеденты «Передача данных» и «Сбор данных», а также весь процесс работы
модуля представлены на рисунке 2.4. Сначала модуль сбора данных подписывается на
рассылку с MQTT брокера, который отправляет параметры, собранные с датчиков через
контроллеры. Далее модуль сбора данных проверяет базу данных MSSQL на наличие
28
информации
о
выбранном
пользователем
датчике
и
записывает
данные
в
преобразованном виде в InfluxDB.
Сбор и передача данных
Модуль сбора данных
MQTT
Контроллер
Датчик
Запрос данных с
контроллера
Запрос данных о
состоянии датчика
Измерение состояния
Начало
Подключение к MQTT
брокеру
Сбор данных с
датчика и передача
MQTT брокеру
Сбор данных с
контроллера и
передача в App C#
Принятие данных с
брокера
Запрос ID
контроллера из
MSSQL
Замена названий
измерений на данные
из MSSQL
Отправка данных в
InfluxDB
Конец
Рисунок 2.4. Сбор и передача параметров
2.4.
Диаграммы последовательностей
Для описания последовательности действий каждого прецедента были построены
диаграммы последовательностей. На данной диаграмме показан жизненный цикл
какого-либо определённого объекта на единой временной оси и взаимодействие акторов
в рамках какого-либо определённого прецедента.
Рисунок 2.5 содержит описание сценария взаимодействия модуля сбора и
передачи параметров со всеми подключенными к нему компонентами.
29
Контроллер
Модуль
MQTT
MS SQL
Подключение
Сбор данных с контроллера
Передача параметров
Запрос данных о контроллере
Отправка данных
Замена названий измерений
Рисунок 2.5. Диаграмма последовательностей
Сначала контроллер подключается к сети Wi-Fi, и MQTT брокер собирает с него
параметры. Далее полученные данные модуль собирает с брокера и берет из БД MSSQL
соответствующие названия и характеристика для контроллера. После этого модуль
записывает все данные в таблицу в InfluxDB.
2.5.
Диаграмма классов
Диаграмма классов (см. рис. 2.6) определяет типы классов системы и различного
рода статические связи, которые существуют между ними. На диаграммах классов
изображаются также атрибуты классов, операции классов и ограничения, которые
накладываются на связи между классами.
Класс «Здание»: класс, включающий информацию о здании.
Атрибуты: личный номер (int), название (string), адрес (string).
Класс «Помещение»: класс, включающий информацию о помещении.
Атрибуты: личный номер (int), название (string).
Класс «Устройство»: класс, включающий информацию об устройстве.
Атрибуты: личный номер (int), название (string).
30
Класс «Контроллер»: класс, включающий информацию о контроллере.
Атрибуты: личный номер (int), название (string).
Здание
Устройство
*
-ID: int
-Название: str
-Адрес: str
-Выбор здания(ID, Название,
Адрес)
-ID: int
-Название: str
-Выбор устройства(ID,
Название)
*
1
Принадлежит
Принадлежит
Принадлежит
1
*
Помещение
*
Настройки
-ID: int
-Название: str
-Значение: str
Принадлежит
Контроллер
1
1
-ID: int
-Название: str
-Выбор контроллера(ID,
Название)
1
-ID: int
-Название: str
-Выбор помещения(ID,
Название)
Принадлежит
*
1
Состояние
Принадлежит
-ID: int
-Название: str
-Значение: str
*
1 Переменные
1
-ID: int
-Название: str
-Значение: str
*
*
Исходящие
Входящие
-ID: int
-Номер: int
-ID: int
-Номер: int
1
1
*
*
Актуатор
Датчик
-ID: int
-Тип: str
-Минимальное значение: int
-Максимальное значение: int
-ID: int
-Тип: str
-Минимальное значение: int
-Максимальное значение: int
Рисунок 2.6. Диаграмма классов
Класс «Настройки»: класс, включающий информацию о настройках контроллера.
Атрибуты: личный номер (int), название (string), значение (string).
Класс «Состояние»: класс, включающий информацию о состоянии контроллера.
Атрибуты: личный номер (int), название (string), значение (string).
Класс «Переменные»: класс, включающий информацию о переменных с
контроллера.
Атрибуты: личный номер (int), название (string), значение (string).
31
Класс «Входящие переменные»: класс, включающий информацию о входящих
переменных с контроллера.
Атрибуты: личный номер (int), номер (int).
Класс «Датчик»: класс, включающий информацию о датчике.
Атрибуты: личный номер (int), тип (string), максимальное значение (int),
минимальное значение (int).
Класс «Исходящие переменные»: класс, включающий информацию об исходящих
переменных на контроллер.
Атрибуты: личный номер (int), номер (int).
Класс «Актуатор»: класс, включающий информацию об актуаторе.
Атрибуты: личный номер (int), тип (string), максимальное значение (int),
минимальное значение (int).
В построенной диаграмме классов отражается статическая модель базу данных
Менеджера сценариев с точки зрения ее проектирования.
2.6.
Диаграмма компонентов
Диаграмма компонентов на рис. 2.7 отображает разбиение программной системы
на структурные компоненты и связи между ними.
Grafana
Influx DB
Arduino
Параметры
Модуль сбора
Данных C#
MQTT
Название тэгов (полей)
MQTT
Lens
MS SQL
Рисунок 2.7. Диаграмма компонентов
32
Данная диаграмма отображает процесс взаимодействия компонентов системы,
необходимых для работы модуля сбора и передачи параметров. Данные с датчика,
измеряющего температуру воздуха, отправляются в контроллер Arduino, далее
попадают в MQTT брокер, который представляет их с помощью расширения для
браузера MQTT Lens. Далее модуль собирает значения параметром контроллера с
брокера и характеристики, и название контроллера из MS SQL и записывает в InfluxDB.
Веб-инструмента для визуализации данных Grafana собирает данных из БД и
отображает их на дашборде.
2.7.
Диаграмма развертывания
Диаграмма развертывания показывает топологию системы и распределение
компонентов системы по ее узлам, а также соединения - маршруты передачи
информации между аппаратными узлами.
Датчик
Температуры
1
Датчик
Температуры
2
Датчик
Температуры
3
Датчик
Температуры
4
Серверы
Контроллер
Модуль сбора
данных
Сервер
Influx
Сервер
Grafana
Рисунок 2.8. Диаграмма развертывания
Рис. 2.8 отображает графическое изображение элементов и компонентов модуля
сбора данных.
33
Глава 3. Программная реализация модуля сбора данных
В третьей главе будет представлено описание реализации программной системы:
построение модели поведения системы, подключение к MQTT брокеру, подключение и
запись данных в InfluxDB. Также на данном этапе будет выполнено тестирование
модуля сбора данных и представлены результаты тестов.
3.1.
Системная архитектура
На рис. 3.1 отображена архитектура взаимодействия компонентов, необходимых
при реализации модуля сбора и передачи параметров инженерного оборудования
технологии Умного дома.
Устройство
Датчик
t1
t2
t3
t4
Arduino
Контроллер
ESP8266
192.168.0.109
MS SQL
Жалюзи
192.168.0.102
Web-камера
192.168.0.101
Модуль сбора
данных
Лампа
192.168.0.103
WAP
Dlink
192.168.0.1
LAN HSE
Internet
t1, t2, t3, t4
MQTT Broker
Mosquitto :1883
Influx DB
Сервер
Мой компьютер
192.168.0.100:1883
MQTT Lens :1883
Порт
Grafana
Рисунок 3.1. Системная архитектура
Имеются четыре датчика температуры типа read-only (только чтение), которые
подключаются к контроллеру Arduino и передают в него свои значения. Вместе датчики
и контроллер образуют устройство. А также имеются устройства управления, например,
это - лампа, жалюзи и веб-камера, при подключении к общей сети LAN HSE Internet они
получают свой IP-адрес.
34
Все контроллеры подключены к Wi-Fi, который в свою очередь подключается к
компьютеру, на котором будет реализован модуль сбора данных. Данный компьютер
подключен к серверу, на котором установлены брокер MQTT Mosquitto, MQTT Lens и
модуль сбора данных, кроме этого имеются такие инструменты как InfluxDB и Grafana.
Данные с датчиков собирает MQTT брокер и отображает в браузере с помощью
расширения MQTT Lens, далее параметры с определенного контроллера передаются в
модуль сбора данных, который в свою очередь через ID контроллера берет из базы
данных MS SQL соответствующие характеристики и название контроллера. Далее
параметры будут записываться в табличном виде в Influx DB, где все данные будут
приведены в правильную форму: каждому фактическому параметру контроллера будет
соответствовать его ID.
Рисунок 3.2. Параметры с датчика температуры
На рис. 3.2 можно увидеть в каком виде передаются данные с контроллера в
MQTT брокер, а далее в InfluxDB: временная метка, хост компьютера, значение
температуры с датчика №1, значение температуры с датчика № 2, значение температуры
с датчика №3, значение температуры с датчика № 4, топик.
Топики представляют собой символы с кодировкой UTF-8. Иерархическая
структура топиков имеет формат «дерева», что упрощает их организацию и доступ к
данным. Топики состоят из одного или нескольких уровней, которые разделены между
собой символом «/».
Необходимо заменить названий измерений на данные из БД. «Topic» должен
содержать следующие параметры «ID контроллера/variables/in», где «in» определяет
номер соответствующего столбца для датчика.
Пример топика в который датчик температуры №1, расположенный на кухне
публикует данные брокеру «123456(ID контроллера)/variables/in1».
35
3.2.
Разработка модуля сбора данных
Сначала необходимо было создать базу данных в MS SQL Server. Для реализации
модели данных использована технология .Net Entity Framework (рис. 3.3). Модель EDM
определяет концептуальную модель базы данных.
Рисунок 3.3. Модель EDM
Далее необходимо подключиться к брокеру MQTT Mosquitto. Для этого
необходимо скачать пакет «M2MqttDotnetCore» с помощью встроенного диспетчера
пакетов NuGet. Данная библиотека позволяет взаимодействовать с брокером на языке
C# в Visual Studio (см. рис. 3.4).
36
Рисунок 3.4. Связь с MQTT брокером
Подключение было выполнена успешно, что можно увидеть на рис. 3.5, так как
были получены значения с датчиков температуры.
Рисунок 3.5. Данные с датчиков
37
После подключения MQTT брокера и сбора с него необходимых параметров
переходим к настройке пользовательского интерфейса для возможности выбора
помещения, здания, устройства и контроллера.
В процессе создания приложений в визуальной среде программирования MS
Visual Studio использована возможность создавать графический интерфейс с помощью
Windows Forms.
На рис. 3.6 отображена форма, на которой будет производиться выбор здания,
далее выбор помещения в выбранном здании, далее пользователь будет выбирать
устройство и привязанный к нему контроллер.
Рисунок 3.6. Форма для выбора
Стандартные возможности C# в Visual Studio не предоставляют возможности
подключиться к InfluxDB напрямую, как например, к SQL-server. Для решения этой
проблемы диспетчер NuGet-пакетов предоставляет множество решений, в том числе и
для записи метрик в InfluxDB. Для работы с БД необходимо было скачать пакет
38
«InfluxDB.LineProtocol». Данная библиотека позволяет записывать метрики в InfluxDB
на языке C#.
С помощью команды «create database» была создана база данных «Parameters», в
которую будет осуществляться конечная запись всех параметров (рис. 3.7).
Рисунок 3.7. БД Parameters
Далее в данную БД будет осуществлять запись полученных параметров с
датчиков вместе с их характеристикой из MSSQL.
39
Заключение
В ходе работы был выполнен анализ предметной области. Рассмотрены
имеющиеся платформы для работы с Интернет вещам, а также инструменты и
технологии для реализации системы Умный дом. На основе этого были выявлены
требования для модуля сбора данных и выбраны средства его реализации.
Была выполнена установка и настройка связки технологий, позволяющих быстро
и достаточно просто получить работающий сервис мониторинга: MQTT, InfluxDB,
Telegraf, Grafana.
Выполнено проектирование системной архитектуры информационной системы. В
том
числе
разработаны
диаграммы
вариантов
использования,
активностей,
последовательностей, компонентов и схема системной архитектуры.
Далее был реализован модуль, который осуществляет сбор параметров с датчиков
инженерного оборудования Умного дома, обрабатывает данные и передает их в БД
временных рядов. Было выполнено тестирование модуля при подключении к датчикам
температуры.
40
Библиографический список
1. Викентьева О. Л., Кычкин А. В., Дерябин А. И., Шестакова Л. В. Архитектура
сетевого управляющего комплекса здания на базе IoT устройств // Датчики и
системы. 2018. № 5. С. 32-38.
2. Shih C., Chou J., «Designing CPS/IoT applications for smart buildings and cities»
// IET Cyber-Physical Systems: Theory & Applications. 2016. № 1. С. 3-12.
3. Lobaccaro G., Carlucci S., «A Review of Systems and Technologies for Smart
Homes and Smart Grids» // Energies 2016. 2016. № 9. С. 348.
4. InfluxData: Платформа для сбора, хранения, визуализации и управления
временными
рядами
//
Официальный
сайт
платформы
InfluxData.
[Электронный ресурс] // URL: https://www.influxdata.com/time-series-platform/
(дата обращения: 22.01.2019).
5. Thingsboard:
Интеграционная
платформа
для
Интернета
вещей//
Официальный сайт платформы InfluxData. [Электронный ресурс] // URL:
https://thingsboard.io/docs/iot-gateway/what-is-iot-gateway/ (дата обращения:
23.01.2019).
6. AggreGate: Интеграционная платформа для Интернета вещей// Официальный
сайт платформы Tibbo AggreGate.
[Электронный ресурс] // URL:
http://aggregate.tibbo.com/ru/ (дата обращения: 23.01.2019).
7. Kang D.,Park M., «Room Temperature Control and Fire Alarm/Suppression IoT
Service Using MQTT on AWS» // International Conference on Platform
Technology and Service. 2017. С. 1-5.
8. Asghar M., Mohammadzadeh N., «Design and simulation of energy efficiency in
node based on MQTT protocol in Internet of Things» // International Conference on
Green Computing and Internet of Things. 2015. С. 1413-1417.
9. InfluxDB: База данных временных рядов с открытым исходным кодом//
Официальный сайт платформы InfluxData. [Электронный ресурс] // URL:
https://www.influxdata.com/products/influxdb-overview/
(дата
обращения:
20.03.2019).
10. Telegraf: Интеграционная платформа для Интернета вещей// Официальный
сайт
платформы
[Электронный
InfluxData.
41
ресурс]
//
URL:
https://www.influxdata.com/time-series-platform/telegraf/
(дата
обращения:
20.03.2019).
11. MQTT Mosquitto: Брокер сообщений с открытым исходным кодом //
Официальный сайт брокера Eclipse Mosquitto. [Электронный ресурс] // URL:
http://aggregate.tibbo.com/ru/ (дата обращения: 23.01.2019).
42
Приложение. Техническое задание
Разработка модуля сбора и передачи параметров инженерного оборудования
Умного дома на основе технологий Интернета вещей
Техническое задание
ЗАКАЗЧИК
Доцент каф. ИТБ НИУ ВШЭ – Пермь
_____________ Кычкин А.В.
«___»_____________2019 г.
Пермь 2019
43
1.
1.1.
Введение
Наименование программы
Наименование программы – «Модуля сбора и передачи параметров
инженерного оборудования Умного дома на основе технологий Интернета
вещей».
1.2.
Краткая характеристика области применения программы
Модуль предназначен к использованию в комплексе с другими программами
Умного дома такими, как Менеджер сценариев и Редактор отчетов на кафедре
информационных технологий 3 корпуса НИУ ВШЭ Пермь.
2.
2.1.
Основание для разработки
Основание для проведения разработки
Основанием для проведения разработки является приказ об утверждении ВКР от
14.12.2017 № 8.2.1.7-10/2
2.2.
Наименование и условное обозначение темы разработки
Наименование темы разработки - «Разработка модуля сбора и передачи
параметров инженерного оборудования Умного дома на основе технологий
Интернета вещей».
3.
3.1.
Данная
Назначение разработки
Функциональное назначение программы
информационная
система
будет
позволять
выполнять
автоматизированный сбор состояний устройств, а также значений параметров
окружающей среды, данных с датчиков и передавать всю информацию в базу данных.
3.2.
Эксплуатационное назначение программы
Интеллектуальная система управления домом объединяет отдельные подсистемы
и устройства в единый комплекс. Модуль сбора данных для инженерного оборудования
Умного дома является необходимой частью всей платформы для всей платформы для
44
управления Интернетом и передачи информации на экран пользовательского
приложения. Эта технология обеспечивает связь между устройствами Internet of Things
с использованием Wi-Fi, что позволяет устройствам передавать данные об их статусе в
базу данных.
Практическая
значимость
работы
заключается
в
возможности
использования разработанной системы при управлении зданием, в том числе
освещением, климатом, доступом, водоснабжении и электроснабжении.
Требования к программе
4.
4.1.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения нижеперечисленных
функций:
1. Сбор параметров с MQTT брокера.
2. Замена названий измерений в TOPIC на данные из базы данных Microsoft SQL.
3. Запись данных в СУБД InfluxDB с заданным TOPIC из СУБД MS SQL.
4. Визуальное представление параметров из InfluxDB.
4.2.
Требования к надежности
4.2.1. Требования к обеспечению надежного
(устойчивого) функционирования программы
Надежное
(устойчивое)
функционирование
программы
должно
быть
обеспечено выполнением совокупности организационно-технических мероприятий,
перечень которых приведен ниже:
— организация бесперебойного питания технических средств;
— выполнением
требований
ГОСТ
51188-98.
Защита
информации.
Испытания программных средств на наличие компьютерных вирусов.
4.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания
технических средств (иными внешними факторами), не фатальным сбоем (не
крахом) операционной системы, не должно превышать времени, необходимого на
перезагрузку операционной системы и запуск программы, при условии соблюдения
условий эксплуатации технических и программных средств.
45
Время восстановления после отказа, вызванного неисправностью технических
средств, фатальным сбоем (крахом) операционной системы, не должно превышать
времени,
требуемого
на
устранение
неисправностей
технических
средств
и
переустановки программных средств.
4.3.
Условия эксплуатации
4.3.1. Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны обеспечиваться
заданные характеристики, должны удовлетворять требованиям, предъявляемым к
техническим средствам в части условий их эксплуатации.
4.4.
Требования к организации входных данных
1. Ввод входных данных организован с помощью датчиков.
2. Параметры с датчиков должны храниться в InfluxDB.
4.5. Требования к организации выходных данных
Вывод выходных данных организован на странице браузера c помощью Grafana.
4.6.
Требования к исходным кодам и языкам программирования
Исходный код программы должен быть реализован на языке C#. В качестве
интегрированной среды разработки может быть использована Visual Studio, а также база
данных на SQL Server и технология .Net Entity Framework для построения
концептуальных моделей.
4.7.
Предварительный состав программной документации
Состав программной документации должен включать в себя:
1. Техническое задание.
5.
Стадии и этапы разработки
5.1.
Стадии разработки
Разработка должна быть проведена в три стадии:
1. Разработка технического задания.
2. Разработка архитектуры.
3. Рабочее проектирование.
46
4. Программная реализация модуля.
5.2.
Этапы разработки
На стадии разработки технического задания должен быть выполнен этап
разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные
ниже этапы работ:
1. Техническое задание.
2. Проектирование программы.
3. Реализация программы.
5.3.
На
этапе
разработки
Содержание работ по этапам
технического
задания
должны
быть
выполнены
перечисленные ниже работы:
1. Постановка задачи.
2. Определение и уточнение требований к техническим средствам.
3. Определение требований к программе.
4. Определение стадий, этапов и сроков разработки программы и документации
на неё.
5. Согласование и утверждение технического задания.
На этапе проектирования приложения должны быть выполнены следующие
задачи:
1. Разработка модели поведения системы;
2. Уточнение бизнес-процессов задачи;
3. Разработка структуры программы;
4. Разработка общего описания алгоритма решения задачи.
На
этапе
разработки
программы
должна
быть
выполнена
работа
по
программированию и отладке программы.
На этапе разработки программной документации должна быть выполнена
разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 и
требованием п. «Предварительный состав программной документации» настоящего
технического задания.
47
6.
Порядок контроля и приемки
6.1.
Приемо-сдаточные
Виды испытаний
испытания
программы
должны
проводиться
Приемосдаточные испытания должны проводиться в НИУ ВШЭ в сроки с 23.03.18 по
29.03.18.
Приемосдаточные
испытания
программы
должны
проводиться
согласно
разработанной исполнителем и согласованной заказчиком «Программы и методики
испытаний».
Ход проведения приемо-сдаточных испытаний документируется в Протоколе
проведения испытаний.
6.2.
Общие требования к приемке работы
После проведения испытаний в полном объеме, на основании «Протокола
испытаний» утверждают «Свидетельство о приемке».
48