Файл: Средства разработки клиентских программ (Аспекты разработки клиентских программ в области систем мониторинга для сельского хозяйства).pdf

Рис. 4. Электронная схема

2.5Разработка архитектуры системы мониторинга.

Для определения архитектуры системы мониторинга необходимо определить составные части системы, а также способ коммуникации.

Архитектура будет включать в себя «умную теплицу», серверную часть, расположенную на облачной платформе, клиентское приложение.

Разработка «умной теплицы» представлено на предыдущих подглавах.

Серверная часть представляет из себя облачную платформу, которая отвечает за передачу данных между «умной теплицей» и клиентским приложением, а также за хранением всех полученных данных.

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

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

Приблизительно архитектура системы проиллюстрирована на Рис. 5.

Рис. 5. Схема архитектура системы мониторинга с базой данной.

2.6Разработка метода отправки данных.

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

Представление архитектуры с использованием протокола проиллюстрировано на рис. 6.

Рис. 6. Схема архитектуры системы мониторинга с протоколом передачи данных MQTT

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

2.7Выбор используемых сервисов в облачной платформе.

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

1. Internet of Things Platform – сервис регистрации и управления устройствами в рамках концепции Интернета вещей. Данный сервис позволяет реализовать MQTT-соединение «умной теплицы» в качестве издателя или/и подписчика к серверу-брокеру, расположенному на облачной платформе, а также обеспечивать соединения других устройств к серверу-брокеру для получения данных с издателя.
2. Cloudant NOSQL DB – сервис, обеспечивающий сервером базы данных, предлагающий хранение данных в виде JSON-документов.

Данные сервисы обеспечат нужными функциями серверную часть системы.

Для реализации функции хранения данных в базу данных необходимо развернуть приложение на облачной платформе, которое будет перенаправлять поток данных с издателя, подключенный через сервис Internet of Things Platform, на сервис базы данных Cloudant NOSQL DB. Из предложенных программных средств самым оптимальным вариантом будет использование визуальной программной среды NODE-RED. Данный программный продукт позволяет управлять потоком данных и преобразовывать его. Разработка приложения в данной среде очень просто и интуитивно, при этом позволяет разрабатывать сложные приложения. Поток данных представлен в формате JSON.

Для визуализации данных пользователю необходима клиентская часть системы. Данная часть представлена в виде клиентского приложения для мобильных устройств на Android ОС.

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

1. Минимум два экрана необходимо. Первый экран должен быть экраном авторизации, где пользователь введет данные, необходимые для получения соединения с облаком. Второй экран рассчитан на вывод уведомлений о полученных сообщениях.
2. Уведомления должны выводиться в виде списка.
3. Возможность включения и выключения уже создавшегося подключения.

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

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

Рис. 7. UML диаграмма последовательности: авторизация пользователя.

Рис. 8. UML диаграмма последовательности: получение данных с сервера.

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

На рис. 9 представлена диаграмма UML вариантов использования клиентского приложения.

Рис. 9. UML вариантов использования: клиентское приложение

Так как это первое клиентское приложение, то и функционал пока очень мал. Пользователь может только авторизоваться для получения данных и получать эти данные.

Приложение будет поддерживать и современные, и более старые версии Android OS. Тестирование будет происходить с помощью Android Virtual Device, доступное вместе с Android Studio в комплекте. Android Virtual Device эмулирует существующие мобильные устройства на настольных компьютерах, тем самым позволяя не прибегать к использованию реальных устройств для тестирования.

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

ГЛАВА 3 ПРАКТИЧЕСКАЯ ЧАСТЬ

Создание датчиков

Из соображений безопасности электронная схема актуатора была переделана. Для разграничения напряжений был добавлен отпрон, состоящий из фотодиода и фоторезистора в закрытом корпусе. Взаимодействие между двумя линиями происходит при помощи света, и исключает все возможные варианты повреждения микрокомпьютера от электричества. Электрическая схема актуатора приведена на рис. 10. Вход 1 и вход 2 управляют вращением актуатора. Синим и красным обозначены управляющие линии. Запрещено подавать напряжение сразу на два входа.

Рис. 10. Электрическая схема актуатора.

По электронной схеме, представленной на рис. 14 был собран макет управляющей части. Он представлен на рис. 15.

Рис. 11. Плата управления актуатором.

Окончательная версия актуатора представлена на рис. 16. В синей коробке находится схема управления актуатором. Сам актуатор работает от 12 вольт, поэтому два крайних провода справа (коричневый вольт и розовый) это питание актуатора. Три левых провода работают от 5 вольт и управляют направлением поворота актуатора. Управление происходит при помощи передачи данных через оптроны. По данному прибору можно дать следующее описание:

• коричневый провод - +12 вольт (питание актуатора);
• розовый провод - земля (питание актуатора);
• белый провод - +5 вольт (управление актуатором, открытие крышки);
• желтый провод - +5 вольт (управление актуатором, закрытие крышки);
• фиолетовый провод – общая земля для белого и желтого проводов (управление актуатором).

Рис. 12. Собранный актуатор

Так как в проекте используются датчики измерения влажности воздуха DHT11, которые не могут измерить влажность почвы, были собраны собственные датчики для измерения влажности. По схеме представленной на рис. 13, сами датчики показаны на рис. 14. Данный датчик срабатывает, когда электрический сигнал проходит между двумя штырями, что свидетельствует о влажности почвы. Когда же почва сухая, электрический сигнал не будет передаваться между штырями. Описание данного прибора следующее:

• фиолетовы провод - +5 вольт, питание устройства;
• желтый провод - земля, питание устройства;
• белый провод - данные о влажности почвы.

Рис. 13. Схема датчика для измерения влажности почвы.

Рис. 14. Собранные датчики для измерения влажности.

• 1. Создание прототипа

Для тестирования системы был собран прототип системы мониторинга в виде теплицы, содержащей два уровня, и протестирован. Построенный прототип, с открытой крышкой, вместе с микрокомпьютером изображен на рис. 15. Микрокомпьютер можно увидеть справа на изображении, он подключен к проектору для отладки системы, так как во время использования, у системы не будет монитора. Как видно из прототипа, лампа (в случае прототипа светодиодная лента) используется одна на оба уровня.

Рис. 15. Прототип теплицы с микрокомпьютером

Также на рис. 16-17 можно увидеть использование в прототипе самодельных актуатора и датчика влажности.

Рис. 16. Расположение актуатора в прототипе

Рис. 17. Расположение датчика влажности в прототипе

Окончательный вид прототипа показан на рис. 18, так как на рис. 19 дверца теплицы была снята, для того чтобы было хорошо видно содержимое теплицы.

Рис. 18. Окончательный вид прототипа

3.3 Тестирование системы

Данные, полученные при тестировании можно увидеть на рис. 23. К первому уровню теплицы относятся: T1, H1, T2, H2, H3, state1. Ко второму уровню теплицы относятся переменные T3, H4, T4, H5, H6, state2. Переменная Ev относится к обоим уровням сразу.

Рис. 19 Тестирование системы

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

Также, система мониторинга отправляет данные на облачную платформу. Данные отправляются в формате json. Фрагмент кода программы, создающей json, приведен в прил. 2 На облако отправляются все данные, показанные при тестировании системы.

3.4 Анализ полученных результатов.

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