Ресиверы.

Необходимы для аккумулирования данных с датчиков. Собирает данные с датчиков и находится в постоянной активности. Нужен для обработки запросов от отдельных датчиков и отправки на балансер. Состоит из самого ресивера и базы данных, в которой поддерживается тройная рандомизированная репликация. Для каждого датчика доступен не только локальный ресивер, но и другие ресиверы. Это позволяет сохранить работоспособность системы в критических случаях. На уровне ресивера должна быть реализована политика балансировки нагрузки, так как некоторые датчики могут не иметь локальных ресиверов. Алгоритм работы заключается в том, что датчик отправляет запросы на ресивер и получает ответы о получает ответ о доступности. Если датчик не получает ответ от локального ресивера, он отправляет широковещательный сигнал на другие ресиверы в зоне видимости данной сети. После получения ответа от удалённого ресивера происходит отправка информации через него. Эта схема является более практичной и отказоустойчивой. В качестве системы управления базы данных ресивера хорошо подойдёт SQlite, так как в базе данных необходимо хранить большое количество одинаковых структурированных данных, а также, данный продукт достаточно компактный для встраивания в ресивер. Ещё одним плюсом в пользу SQlite является то, что исходный код данной СУБД находится в открытом доступе. Если провести аналогию, то ресивер – это доска объявлений. Датчики приходят и в определённые места вешают информацию по своему текущему состоянию. В свою очередь сбор информации происходит последовательным считыванием данных объявлений.

Буфер.

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

Клиентская часть.

В данной работе рассматриваются несколько вариантов для реализации клиентской части. Первым вариантом можно рассматривать создание отдельных приложений для работы с функционалом данной системы. Для прототипа данный вариант подходит отлично, также для первоначального тестирования, так как в данном приложении не будет большого функционала. Основными функциями клиентской части приложения будет просмотр показания датчиков и расчёт текущего долга. Второй вариант подходит к реализации в итоговой версии. Он заключается во включении данного функционала в уже имеющееся приложение как дополнительный функции. Такая реализация позволит уменьшить количество приложений у пользователя, что уменьшит количество отрицательных реакций, а также станет дополнительным рекламным ходом для других пользователей банковского приложения [42].

---

Для написания приложения под Android можно использовать такие языки программирования как Kotlin или Java. В проектируемой модели предполагается использование Kotlin для написания данного приложения потому, что данный язык программирования обладает следующими свойствами [43]:

• 
  Компилируется в JavaScript и в байт-код JVM.
  
• 
  Поддерживает все существующие Java-фреймворки и библиотеки.
  
• 
  Простой для изучения.
  
• 
  Открытый исходный код.
  
• 
  Существует автоматическая конвертация в Java и обратно.
  
• 
  Имеет проверку на Null результат.
  

Для написания приложения под iOS в модели рассматриваются такие языки как Swift и React Native. Проект предполагает использование Swift, так как это компилятор с открытым исходным кодом, а также создан компанией Apple специально для разработчиков под iOS и macOS [44].

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

Также в данной модели учитывается вариант создания Web интерфейса для удобства взаимодействия с данной системой [45].

Приложение для управляющей компании.

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

Управляющая компания.

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

Кластер
Рисунок 19. Структурная схема кластера

---

Кластер состоит из некоторого набора Node, которая является основной серверной частью. Каждая из таких Node состоит из агрегатора и базы данных.

Агрегатор.

Агрегатор отвечает за работу с данными. Он умеет обрабатывать полученные данные, конвертировать их в формат, приемлемы для хранения и сохранять их в базу данных. Также агрегатор умеет обрабатывать запросы пользователей и применять необходимые модели работы с запросами и данными. Также рассматривается вариант обучения данного агрегатора при таковой необходимости [46].

База данных.
Рисунок 20. Схема базы данных


Отвечает за агрегирование, обработку и хранение данных, полученных от счётчиков. Для данной базы данных необходимо учитывать, что система управления базой данных должна справляться с большим количеством запросов. В качестве такой СУБД выбрана PostgreSQL. Она является объектно-реляционной СУБД и обладает большим количеством поддерживаемых типов данных, а также, имеет открытый исходный код и обеспечивает целостность данных. Также данная СУБД поддерживает расширение функционала, за счёт возможности сохранения своих процедур [47].

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


9. Агрегация данных
Для реализации агрегации данных подойдёт Apache Spark. Spark – это фреймворк с открытым исходным кодом, предназначенный для обработки слабоструктурированных данных. В этом фреймворке используются специальные примитивы для обработки в оперативной памяти, что позволяет получить высокую скорость работы системы, особенно при необходимости многократного доступа к загружаемым в память данным пользователя. Агрегатор данных позволит создавать и анализировать полученную информацию, вести отчётность и статистику [48].
Рисунок 21. Схема агрегатора

---

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


10. Реализация
При реализации тестового прототипа были подготовлены ресивер и кластер по обработке запросов. Для создания ресивера были использованы три Raspberry Pi Zero W+, объединённые в одной WiFi сети. Питание было организовано через usb адаптеры с понижением напряжения до 5В. При создании кластера были использованы шесть Raspberry Pi 3В+ объединённые в локальную сеть с пропускной способностью в 100 мб/с.
Рисунок 22. Пример кластера


Результатом тестов стали следующие значения:

Потребление энергии ресивер в режиме простоя составило 0.5 Втч. Потребление ресивера в режиме нормально работы без нагрузок составило 0.9 Втч. Потребление ресивера в режиме работы под нагрузкой составило 1.2 Втч.

Потребление энергии кластера в режиме простоя составило 1 Втч. Потребление кластера в режиме нормально работы без нагрузок составило 1.5 Втч. Потребление кластера в режиме работы под нагрузкой составило 2.5 Втч.

При данном потреблении была получена следующая производительность:

3276 операций/с по вводу информации и 3964 операции/с по считыванию информации.

Рисунок 23. Результат тестирования 5 Raspberry Pi в кластере


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

---

Для распространения данной системы можно использовать несколько стратегий:

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

12. Выводы
Разрабатываемая модель обладает рядом преимущество относительно систем, имеющихся на данный момент:

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

---

Смотрите также файлы

• Литература Введение Автоматизация производственных процессов одно из наиболее важных направлений научнотехнического развития.rtf

• Реферат по дисциплине Педагогика По теме Место педагогической науки в системе наук.docx

• Практическое занятие 1 Тема Экономические потребности, блага и ресурсы. Проблема выбора.docx

• Вопрос Вопрос 2.docx

• 1 Понятие, виды и объекты конституционного контроля.docx