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

Содержание:

ВВЕДЕНИЕ

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

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

Как объект исследования в данной работе можно выделить систему мониторинга для сельского хозяйства с использованием технологий свойственных для Интернета вещей.

Предметом данного исследования является система мониторинга для сити-фермерства в рамках концепции Интернета вещей.

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

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

Для достижения данной цели требуется выделить основные задачи работы.

1. Для сбора данных с растений, а также их ухода необходимо создать прототип особой теплицу, позволяющая совершать данные действия. Их называют «умными теплицами». Они позволяют с помощью сенсоров собирать данные с растений, такие как температура, влажность и яркость, а также с помощью некоторых механизмов контролировать полив воды и проветривание пространства.
2. Чтобы пользователь мог постоянно иметь контроль к собственной теплицы, все данные должны собираться в одном хранилище. Данным хранилищем будет служить сервер на облачном пространстве. Облачные вычисления происходят на многочисленных в сети серверах, которые предоставляются пользователям сторонними лицами. Облачное хранилище представляет из себя с точки зрения пользователя один большой виртуальный сервер, предоставляющий ему множество сервисов для использования. Облачные платформы очень устойчивы к сбоям, и поэтому они доступны буквально постоянно, что очень важно для постоянной работы с сетью.
3. Пользователь должен получать доступ к данным с устройств, которые есть у большинства. Такими устройствами являются мобильные девайсы и персональные компьютеры. С помощью их пользователь должен просматривать все данные с облачного хранилища, осуществлять управление теплицей и так далее.

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

ГЛАВА 1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ КЛИЕНТСКИХ ПРОГРАММ В ОБЛАСТИ СИСТЕМ МОНИТОРИНГА ДЛЯ СЕЛЬСКОГО ХОЗЯЙСТВА

Объекты систем мониторинга

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

• открытая окружающая среда;
• теплицы;
• домашние теплицы.

В связи с тем, что человека интересуют только параметры состояния среды в каком-то определенном месте, то данные объекты можно свести к понятию микроклимата.

Микроклимат. Микроклимат - это состояние среды в каком-то определенном замкнутом пространстве или на открытой местности, с указанием четких границ [1]. Данный термин наиболее подробно описывает состояния небольших теплиц, как домашних, так и теплиц на сельскохозяйственных участках. Основные параметры, которые описывает микроклимат это: температура и влажность воздуха, температура и влажность грунта, освещенность. Также, сами растения могут принимать участие в формировании климата, тогда это уже будет фитоклимат. Из особенностей микроклимата можно выделить одну наиболее важную – это скорость изменения климата, так как, объем наблюдаемой территории ограничен, и зависит не только от внешних условий, но и от активности внутри, это очень сильно сказывается на изменении параметров. В силу объема у микроклимата почти отсутствует инертность. Понятие микроклимата во всю используется в сити-фермерстве, так как объем теплиц сравнительно мал, и в виду нахождения в городских условиях существует множество способов быстрого изменения параметров климата. Именно за такими теплицами должен происходить постоянный мониторинг.

Cити-фермерство. Сити-фермерство это выращивание сельскохозяйственных культур, в городских условиях, используя при этом современные технологии, такие как, интернет вещей. Цели сити-фермерства - это сознать необходимое изобилие продуктов для нуждающихся людей, поддерживая и поощряя создание садов на неиспользуемых землях и в неиспользуемых помещениях в городском массиве, а также на крышах зданий, одновременно увеличивая разнообразие, повышая осведомленность об употребляемых продуктах питания, а также создания здорового образа жизни [2]. Помимо всего этого, сити-фермерство способствует созданию небольших ферм для ведения частного бизнеса.

В виду того, что сельскохозяйственный сектор не является передовым с точки зрения внедрения новых технологий, и уступает по скорости внедрения таким секторам как, например, банковский или медицинский, спрос на новые разработки в сельскохозяйственном секторе не велик. Однако недавно появившиеся сити-фермерство вносит свои корректировки. Впервые вертикальная ферма была построена в Сингапуре в 2012 году. [3] В виду высокой плотности населения 5 млн. жителей на 710 квадратных километров и высоком импорте продуктов 93 процента такое движение при помощи государства получила огромную популярность [4]. В России движение сити-фермерства только зарождается, поэтому создание систем мониторинга именно для домашних теплиц для сити-фермеров очень актуально.

• 1. Средство сбора и отправки

Интернет вещей – это сеть физических устройств, со встроенными технологиями для обмена и сбора данных или для взаимодействия со своими внутренними состояниями или внешней средой [5]. В настоящее время Интернет вещей набирает все большую популярность, особенно для использования различных датчиков и микроконтроллеров.

Для решения проблемы получения данных из окружающей среды и последующей их обработки, необходимо использовать специальное аппаратное решение, обеспечивающие необходимый функционал. В виде такого устройства может выступать микроконтроллер или одноплатный компьютер. Наиболее распространенными решениями являются: микроконтроллер Arduino и микрокомпьютеры Raspberry Pi, Orange Pi и Banana Pi. Данные устройства обладают малыми габаритами при этом позволяют обрабатывать множества данных, получать и вырабатывать сигналы с помощью внешних входов, отправлять по ним множество информации и т.д. Технология Интернета, вещей благодаря данным устройствам, стала доступна большинству людей, что и позволяет реализовать проекты «умных» домов, «умных» теплиц и других разных проектов без проектирования и создания специальной платы. Все выше приведенные устройства могут быть использованы как средство сбора и отправки информации, однако они имеют сильные различия в комплектации. Микроконтроллер Arduino не имеет множества важных для проекта интерфейсов, такие как Ethernet или Wi-Fi, такие интерфейсы могут быть доступны только при приобретении отдельных модулей, цена которых примерно сопоставима с ценой самой платы, что накладывает существенные ограничение на простоту использования устройства. Также, в отличии от одноплатных компьютеров Raspberry Pi, Orange Pi и Banana Pi микроконтроллер Arduino не имеет функции удаленного управления и перепрограммирования, что значительно осложняет пользование этим устройством, так как внести изменения в существующую программу и настроить устройство можно только подключив устройство только при подключении через интерфейс USB к компьютеру. Исходя из данных недостатков, было решено использовать микрокомпьютерные решения от Raspberry Pi, Orange Pi и Banana Pi.

Главным критерием для сравнения Raspberry Pi, Orange Pi и Banana Pi было наличие интерфейса для выхода в Интернет, а именно хотя бы одного из двух: Ethernet или Wi-Fi. Следующим критерием оценки является цена, так как высокая стоимость одноплатного компьютера отобразиться на стоимости всей системы. В более дорогих версия в микрокомпьютер включено не только большее количество интерфейсов, но и сами характеристики кристалла лучше, такие как тактовая частота и оперативная память. Что является хорошим дополнением, так как при лучших показателях частоты и оперативной памяти, увеличится не только скорость работы компьютера, что позволит собирать данные с меньшим периодом ожидания между снятием показаний с датчиков, но и позволит опрашивать большее количество датчиков одним микрокомпьютером. При следовании данным критерия выбор пал на устройство семейства Orang Pi, а именно на Orange Pi 2G-IOT. Что не удивительно, ведь данное устройство специально было разработано для проектов Интернета вещей, и сочетает в себе не плохую частоту, доступ Wi-Fi и небольшую цену. Однако на Российском рынке достать такую плату весьма проблематично. Очень малое количество магазинов предлагают данную линейку плат в виду того что изготавливаются и продаются они преимущественно в КНР. Также минусом является длительное время доставки при покупке через Интернет из Китая. Тоже самое можно сказать и про Banana Pi, данная линейка тоже распространяется преимущественно по Китаю. В результате, выбор пал на серию Raspberry Pi. Raspberry Pi – самая доступная серия микрокомпьютеров на рынке. Компания Raspberry Pi Foundation - первая, кто выпустила в большой тираж компьютер размером с кредитную карту, обладающая возможностями полноценного компьютера, что породило новый тренд на рынке информационных технологий. С момента появления Raspberry Pi образовалось многочисленное сообщество, в котором делятся разными разработками и методами использования данных микрокомпьютеров. Как и было сказано, Raspberry Pi породило новый тренд создания компьютеров размером с кредитную карту, в связи с этим китайскими разработчиками было представлено множество аналогичных решений, в том числе Orange Pi и Banana Pi. Данные серии микрокомпьютеров набирает стремительно популярность благодаря меньшей цене по сравнению с Raspberry Pi, и обладанием лучших характеристик частоты и оперативной памяти. Применяя алгоритм выбора устройства для сбора данных исключительно к линейке Raspberry Pi, был выбран вариант Raspberry Pi 1 B, так как обладает наименьшей ценой из всего семейства. Результаты сравнения приведены в табл. 1. разные семейства устройств для удобства выделены разными цветами, Orange Pi – оранжевым, Raspberry Pi - красным, Arduino - синим, Banana Pi - зеленым.

Таблица 1

Сравнение управляющих устройств

Model	CPU Frequency	Ram	Wi-Fi	Ethernet	Price
Orange Pi 2G-IOT	1 GHz	256 MB	+	-	10$
Orange Pi PC	1.6 GHz	1 GB	-	+	15$
Orange Pi Plus2	1.6 GHz	2 GB	+	+	49$
Raspberry Pi 1B	700 МHz	512 MB	-	+	26$
Raspberry Pi 2	900 MHz	1 GB	-	+	35$
Raspberry pi 3B	1,2 GHz	1 GB	+	+	60$
Arduino Nano	16 МHz	2 KB	-	-	25$
Arduino Uno	16 MHz	2 KB	-	-	30$
Arduino Mega 2560	16 MHz	8 KB	-	-	50$
Banana Pi M2 Zero	1 GHz	512 Mb	+	-	16$
Banana Pi M1	1 GHz	1 GB	-	+	32$
Banana Pi R2	1.3 GHz	2 GB	+	+	89$

• 1. Средство представления (облачная платформа)

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

Облачные вычисления - модель предоставления удобного сетевого доступа в режиме «по требованию» к коллективно используемому набору настраиваемых вычислительных ресурсов (например, сетей, серверов, хранилищ данных, приложений и/или сервисов), которые пользователь может оперативно задействовать под свои задачи и высвобождать при сведении к минимуму числа взаимодействий с поставщиком услуги или собственных управленческих усилий[6].

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

1. Самообслуживание по требованию – потребитель самостоятельно имеет возможность использовать те или иные вычислительные возможности без надобности обращения к поставщику.
2. Широкая доступность через Интернет – с помощью любого устройства, имеющим доступ к Интернет сети, потребитель может обращаться к облаку.
3. Объединение ресурсов в пул – все физические и виртуальные ресурсы объединяются в один пул, который доступен потребителю. Сам потребитель не имеет знаний о местонахождении ресурсов на составляющих облаков.
4. Быстрая адаптация ресурсов – все ресурсы облака, которые использует потребитель, масштабируются в зависимости от возможностей самого потребителя. К примеру, потребитель может потребовать больше ресурсов на какой-либо проект. Он может сразу же расширить их, дополнительно оплатив за это, без обращения к поставщику. Также, имеет место пример, в котором потребитель, наоборот, меняет тариф, где предоставляется меньше ресурсов.
5. Измеримая услуга – все ресурсы, предоставляемые поставщиком, оцениваются, контролируются и управляются через измеряемые абстрактные параметры. Данные параметры влияют на оказание услуг.
6. Надежность – облачные ресурсы по сравнению с локальными имеют гораздо выше надежность, так как вероятность возникновения проблем с облаком крайне мала.

Описанные характеристики облачных технологий описывают их преимущества по сравнению с использованием других сервисных программных и аппаратных обеспечений в сети Интернет.

Все модели обслуживания облачных вычислений делятся на три категории:

1. SaaS (Software as a Service) – потребителю предоставляется ПО, работающее на облачных вычислениях (Примеры: Google Drive, Dropbox)
2. PaaS (Platform as a Service) – потребителю предоставляются средства для развертывания на облачных вычислений собственные ПО, которые могут быть созданы с помощью предоставляемых самим поставщиком инструментов.
3. IaaS (Infrastructure as a Service) – потребителю предоставляется возможность развертывание произвольного ПО, в том числе и операционные системы.

Для реализации системы мониторинга наилучшим вариантом модели предоставления облачных вычислений будет PaaS.

Существует множество облачных платформ от различных крупных IT-компаний. К примеру, Windows Azure от Microsoft, Beanstalk от Amazon, Bluemix от IBM. Выбор облачной платформы осуществлялся среди выше предложенных.

Оценивались следующие требования от PaaS: доступность, предоставляемые услуги и ресурсы. Все три облачные платформы предоставляют бесплатный доступ к своим сервисам. Это возможно при наличии студенческого удостоверения. Среди предоставляемых услуг и ресурсов следующие были самыми предпочтительными: сервисы работы с Интернетом Вещей, сервисы базы данных. Каждая платформа предоставляет почти одинаковый набор необходимых сервисов и ресурсов.

Кроме данных критериев также оценивалось предоставляемое ПО поставщиками. Поставщики данных платформ предлагают собственные SDK для разработки на популярных языках программирования, а также IDE для разработок на этих языках. Дополнительно, IBM предоставляет собственную визуальную среду программирования NODE-RED, которая управляет потоком информации. Данная среда программирования проста в использовании, интуитивна и позволяет объединять использование облачных сервисов.

После анализа платформ по данным критериям выбор пал на IBM Bluemix как самый оптимальный выбор.

ГЛАВА 2 РАЗРАБОТКА КЛИЕНТСКИХ ПРОГРАММ

2.1Разработка структурной схемы теплицы с расположением датчиков

С точки зрения метрологии, данные с показателя одного датчика не всегда являются надежными, так как в случае, например, с датчиком температуры в теплице, показания могут сильно различаться в случае, когда солнце светит на датчик, и его температура выше, и когда датчик находится в тени, хотя в обоих этих случаях температура в теплице является одинаковой. Более того, промышленные теплицы имеют достаточно большой объем, и показаний одного датчика будет явно недостаточно. Также принимая во внимание то, что по законам физики более теплый воздух поднимается вверх, то температура внизу теплицы и вверху будет различной. Может быть случай, когда температура измеряется одним датчиком, расположенном под крышей теплицы, и находится около нижней границы температуры, когда в теплице должно включиться отопление, но температура внизу теплицы может быть на пару градусов ниже, и растения начнут замерзать. Чтобы такого не случилось необходимо измерять температуру в нескольких независимых местах в теплицы. Например, один датчик находится снизу в углу, и практически измеряет температуру земли, а второй находится сверху в противоположном углу, и измеряет только температуру воздуха. В таком случае, датчики находятся максимально друг от друга и измеряют показания разных сред, что делает совокупность их измерений наиболее правдоподобной.

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

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

Исходя из написанного выше, для создания прототипа двухуровневой теплицы потребуется следующий набор датчиков:

• 4 датчика температуры и влажности DHT11 (по 2 на каждый уровень);
• 2 датчика влажности (по 1 на каждый уровень);
• 1 датчик освещенности LM393 (один на всю теплицу).

Полученная схема с расположением датчиков изображена на рис. 1.

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

На схеме, приведенной выше, использованы следующие обозначения:

• T1, H1 и T3, H4 обозначают температуру и влажность, полученные с датчиков DHT11, находящимся в верхней части 1 и 2 уровнях теплицы;
• T2, H2 и T4, H5 обозначают температуру и влажность, полученные с датчиков DHT11, находящимся рядом с почвой в 1 и 2 уровнях теплицы;
• H3 и H6 обозначают данные о влажности почвы в 1 и 2 уровнях теплицы;
• Ev обозначает данные об освещенности в теплицы, полученные с модуля светочувствительности LM393.

  1. Разработка алгоритма сбора и обработки измеренной информации

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

• если показания с датчика освещенности говорят о том, что уровень освещенности в теплице снизился, это может случиться потому что наступает ночь или солнце ушло за тучи, то система дает сигнал на включение освещения;
• если показания с датчиков о влажности почвы показывают что влажность почвы стала ниже заданного пользователем уровня, то система должна выдают сигнал на полив растений;
• если в теплице температура превышает установленную пользователем, то система должна выдать сигнал на открытие форточки;
• если показания с датчика освещенности говорят о том, что уровень освещенности в теплице повысился, и стал достаточно сильным для установленного режима существования растений, то система дает сигнал на выключение освещения;
• если в теплице температура становится ниже установленной пользователем, то система должна выдать сигнал на закрытие форточки;

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

Рис. 2. Алгоритм сбора и обработки данных измерительной информации

2.3 Разработка схемы подключения датчиков

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

• лампы;
• актуаторы;
• помпы.

Также система должна передавать данные в сеть Интернет, для этого будет использоваться Ethernet модуль. Для получения данных об освещенности используется только один датчик на все уровни, но в каждом уровне установлены свои лампы. Все управляющие и измерительные модули, а также модуль Ethernet подключены к одноплатному компьютеру. Данная схема представлена на риc. 3.

Рис. 3. Схема подключения датчиков.

2.4Разработка электрической схемы

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

В схеме актуатор должен иметь возможность вращаться в обе стороны, чтобы открывать и закрывать окно. Для решения этой задачи будет использоваться Н-мост данная схема на транзисторах позволяет управлять направлением вращения мотора, тем самым регулируя открывание и закрывание окна теплицы [28]. Электронная схема прототипа показана на рис. 8. На данном рисунке провода питания обозначены черным цветом, а провода управления и получения данных синим и красным. Это было сделано для удобной читабельности схемы. Синий и красный провода на моторах, обозначают разные направления вращения этих моторов. В соответствии и принципом работы схемы Н-моста, только один из них может иметь положительное напряжение. Комбинация, когда оба провода передают достаточное напряжение для открытия транзисторов запрещена, так как в таком случае образуется короткий путь, без участия мотора, что ведет к короткому замыканию.

Рис. 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, находящийся на этом же уровне), что позволяет отследить состояние об ошибке. Также, в будущих версиях будет добавлена возможность распознания ошибки в показаниях датчика, с помощью программных средств.

3.5 Развертывание сервера-брокера на облачной платформе

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

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

Рис. 20. Платформа IBM Watson IoT и созданный тип устройства.

После установки и настройки клиента на микрокомпьютере, MQTT-соединение настроено, и данные с «умной теплицы» готовы к отправлению на сервер-брокер.

3.6 Развертывание облачного приложения по хранению в базе данных.

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

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

Сперва необходимо установить и настроить сервис базы данных Cloudant NoSQL DB. Данный сервис предоставляет структурированные базы данных, в которых данные хранятся в виде JSON документов. Учитывая, что данные передаются в формате JSON, то и хранение в этом же формате будет также полезным. JSON имеет структурированный вид, позволяющий представить в любом удобном представлении, к примеру, в виде таблицы. На рис. 21 представлен сервис базы данных Cloudant NoSQL с имеющимися данными.

Рис. 21. Сервис базы данных Cloudant NoSQL.

Среди множества поддерживаемых программных средств, которые предоставляет IBM на своей платформе, самым оптимальным вариантом будет визуальная среда программирования Node-RED. Данная среда программирования позволяет управлять различными потоками данных, а также проводить с ними манипуляции. Среда работает в среде Node.js, где поток данных выражается в формате JSON, а узлы-функции написаны на языке JavaScript. Благодаря данному программному средству, облачное приложение имеет очень простой и компактный вид. Все облачные приложения состоят из узлов и их соединений. Узлы имеют в среде прямоугольный вид, где ввод данных на узел выражен кружочком на левой границе узла, а вывод – на правой границе. Узлы могут выполнять множество функций в зависимости от типа узла. Необходимо отметить, что в приложении можно использовать любые сервисы IBM Bluemix с помощью определенных узлов. Облачное приложение в среде Node-RED представлено на рис. 22.

Рис. 22. Облачное приложение хранения в базе данных в среде Node-RED.

Описывая данное приложение, необходимо отметить следующие узлы:

1. IoT Device Events: узел сервиса Watson IoT Platform, выводящий поток данных с устройств.
2. NewMessage: узел-функция изменения полученного сообщения в потоке данных.
3. Greenhouse_events_new: узел-сервис Cloudant NoSQL, принимающий на вход данные, которые нужно сохранить или удалить.
4. Device data: узел вывода данных в дебаг(вывод данных) приложения.

При поступлении с устройств, подключенные к сервису Watson IoT Platform, данные поступают на функцию, которая изменяет значения и поля сообщения. После работы функции данные отправляются на сервис Cloudant NoSQL, где хранятся в определенной таблице. В то время узел device data выводит данные в приложении для оценивания результата функции.

3.7 Тестирование облачного приложения.

Устройство отправляет изначально данные в формате JSON в виде, проиллюстрированном на рис. 23.

Рис. 23. Данные, приходящие с «умной теплицы» через сервис Watson IoT Platform.

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

Рис. 24. Содержание работы функции-узла, написанная на языке JavaScript.

В итоге, новое сформулированное сообщение будет иметь другие данные. Оно представлено на рис. 25.

Рис. 25. Сформированные данные с помощью функции в среде программирования Node-RED.

Сохраненные данные на сервисе Cloudant NoSQL представлено на рис. 26.

Рис. 26. Сохраненные данные в сервисе Cloudant NoSQL.

Приложение сохранило только часть данных с поля payload. В данном поле содержится именно отправляемые данные «умной теплицей». Оставшиеся поля формируются во время отправления по MQTT. Если необходимо сохранить полностью сообщение, то в облачном приложении существует такая возможность.

3.8 Разработка клиентского приложения.

Цель данного проекта – разработать такую систему мониторинга, которая позволит пользоваться ей на расстоянии с помощью сети Интернет. Чтобы этого достичь необходимо разработать клиентское приложение, позволяющее любому пользователю получить доступ с использованием различных устройств, которые могут иметь доступ к сети Интернет.
Целевой платформой первого клиентского приложения является Android ОС. Разработана с помощью стандартного пакета разработки Android SDK на языке Java.

В ходе разработки использовались следующие библиотеки:

1. Org.eclipse.paho.client.mqttv3 – библиотека, обеспечивающая соединение по протоколу MQTT. Данная библиотека распространяется по бесплатной лицензии компанией Eclipse.
2. Org.json – библиотека, позволяющая работать с данными в формате JSON.

С использованием стандартных и описанных библиотек разработка клиентского приложения прошла успешно.

3.9 Описание клиентского приложения.

Приложение имеет два экрана: экран авторизации и экран уведомлений.

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

1. Наименование организации сервиса. Оно относится к наименованию сервиса, которым пользуется пользователь сервиса. Позволяет разграничивать группы типов устройств, приложений.
2. Ключ API. Данные, необходимые для настройки использования программного интерфейса приложения (API) в ходе создания подключения по MQTT протоколу.
3. Токен аутентификации. Иными словами, пароль, необходимый для подключения по API.

Эти данные необходимо сгенерировать в сервисе Watson IoT Platform на вкладке Apps. На рис. 27 проиллюстрирован сервис Watson IoT Plarform на вкладке Apps.

Рис. 27. Сервис Watson IoT Platform на вкладке Apps.

Данные необходимо ввести на стартовый экран клиентского приложения, которое проиллюстрировано на рис. 28.

Рис. 29. Экран авторизации клиентского приложения.

После авторизации появится второй экран, на котором будет выводиться любая информация, пришедшая с «умная теплица». На рис. 30 проиллюстрирован экран уведомлений с уже пришедшими результатами.

Рис. 30. Экран уведомлений.

Данный экран заполняется автоматически при получении каких-либо данных с издателя MQTT.

Часть кода приложения, выводящего уведомления представлено в прил. 4.

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Город 21 века [Электронный ресурс]. – Режим доступа: http://gorod21veka.ru/list/teplitcy/mikroklimat_teplitc/ - Дата доступа: 11.05.18
2. UrbanFarming [Электронный ресурс]. – Режим доступа: http://www.urbanfarming.org/about.html - Дата доступа: 11.05.18
3. Атлас новых профессий [Электронный ресурс]. – Режим доступа: http://atlas100.ru/catalog/selskoe-khozyaystvo/siti-fermer/ - Дата доступа: 11.05.18
4. Lifedlobe. Весь мир как на ладони [Электронный ресурс]. – Режим доступа: http://lifeglobe.net/entry/5445 - Дата доступа: 11.05.18
5. Gartner. IT glossary [Электронный ресурс]. – Режим доступа: https://www.gartner.com/it-glossary/internet-of-things/ - Дата доступа: 11.05.18
6. Мой склад [Электронный ресурс]. – Режим доступа: https://www.moysklad.ru/poleznoe/statyi/chto-takoe-oblachnye-servisy/ - Дата доступа: 11.05.18
7. Jeonghwan Hwang, Changsun Shin and Hyun Yoe “Study on an Agricultural Environment Monitoring Server System using Wireless Sensor Networks”, MDPI, pp 11189-11211, 2010
8. National Instruments. What is Wireless Sensor Network? [Электронный ресурс]. – Режим доступа: http://www.ni.com/white-paper/7142/en/ – Дата доступа: 11.05.18
9. Yifan Bo, Haiyan Wang “The Application of Cloud Computing and The Internet of Things in Agriculture and Forestry”, IEEE Computer Society, pp 168-172, 2011
10. Кабанов А. А. Автоматизированная система «умная теплица» //РЕСУРСОЭФФЕКТИВНЫМ ТЕХНОЛОГИЯМ-ЭНЕРГИЮ И ЭНТУЗИАЗМ МОЛОДЫХ. – 2015. – С. 275-278.
11. «Умная» теплица от разработчиков EPAM: революция в сельском хозяйстве не за горами [Электронный ресурс]. – Режим доступа: https://dev.by/lenta/main/razrabotchiki-epam-sozdali-umnuyu-teplitsu-revolyutsiya-v-selskom-hozyaystve-ne-za-gorami – Дата доступа: 11.05.18
12. ЭлектроТехИнфо [Электронный ресурс]. – Режим доступа: http://www.eti.su/articles/izmeritelnaya-tehnika/izmeritelnaya-tehnika_443.html - Дата доступа: 11.05.18
13. Новые химические технологии [Электронный ресурс]. – Режим доступа: http://www.newchemistry.ru/letter.php?n_id=9158 - Дата доступа: 11.05.18
14. Преобразователи, датчики, сенсоры [Электронный ресурс]. – Режим доступа: https://sensorse.com/page9.html - Дата доступа: 11.05.18
15. GitHub, Build for developers [Электронный ресурс]. – Режим доступа: https://github.com/adafruit/DHT-sensor-library/blob/master/DHT.cpp - Дата доступа: 11.05.18
16. Амперка [Электронный ресурс]. – Режим доступа: http://amperka.ru/product/thermistor - Дата доступа: 11.05.18
17. Амперка [Электронный ресурс]. – Режим доступа: http://amperka.ru/product/troyka-light-sensor - Дата доступа: 11.05.18
18. ArduinoMaster, Все об ардуино [Электронный ресурс]. – Режим доступа: https://arduinomaster.ru/datchiki-arduino/photorezistor-arduino-datchik-sveta/ - Дата доступа: 11.05.18
19. Arduino+-kit [Электронный ресурс]. – Режим доступа: https://arduino-kit.ru/catalog/id/modul-obnarujeniya-svetochuvstvitelnyiy-lm393- Дата доступа: 11.05.18
20. Hypertext Transfer Protocol -- HTTP/1.0 [Электронный ресурс]. – Режим доступа: https://tools.ietf.org/html/rfc1945 - Дата доступа: 11.05.18
21. Mozilla [Электронный ресурс]. – Режим доступа: https://developer.mozilla.org/ru/docs/Web/HTTP/Methods - Дата доступа: 11.05.18
22. IoT Agenda [Электронный ресурс]. – Режим доступа: https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport - Дата доступа: 11.05.18
23. Whatls.com [Электронный ресурс]. – Режим доступа: https://whatis.techtarget.com/definition/Constrained-Application-Protocol - Дата доступа: 11.05.18
24. AndroidPub [Электронный ресурс]. – Режим доступа: https://android.jlelse.eu/apple-vs-android-a-comparative-study-2017-c5799a0a1683 - Дата доступа: 11.05.18
25. Android [Электронный ресурс]. – Режим доступа: https://developer.android.com/studio/ - Дата доступа: 11.05.18
26. Eclipse [Электронный ресурс]. – Режим доступа: http://www.eclipse.org/downloads/eclipse-packages/ - Дата доступа: 11.05.18
27. JetBrains [Электронный ресурс]. – Режим доступа: https://www.jetbrains.com/idea/ - Дата доступа: 11.05.18
28. Амперка [Электронный ресурс]. – Режим доступа: http://forum.amperka.ru/threads/Помогите-с-h-мостом.4974/ 12.05.2018 - Дата доступа: 11.05.18

Приложения

Приложение 1. Фрагмент кода для микрокомпьютера.

Приложение 2. Фрагмент программы, формирующей json.

Приложение 3. Аномалия в данных.

Приложение 4. Фрагмент кода клиентского приложения, выводящего уведомления.