Система управления автоматизированным тепличным хозяйством

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

1. ПП должен предоставлять возможность ручного управления основными системами теплицы. (Полив, проветривание, освещение);
2. ПП должен осуществлять контроль и вывод информации с датчиков (температура, освещение, влажность воздуха и земли, количество воды для полива, уровень углекислого газа);
3. ПП должен предоставлять дополнительные функции, такие как вывод графиков по данным с датчиков и вывод отчетов в MS Excel;
4. ПП должен обеспечивать создание и редактирование индивидуального профиля для каждого растения;
5. ПП должен осуществлять контроль за состоянием (исправностью) датчиков;
6. ПП должен оповещать пользователя о критических событиях (отсутствие воды в баке для полива)

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

1.3. Обзор существующего  программного обеспечения

В России большое распространение  получили малые тепличные комплексы  и гидропонные микросистемы. В  Хакасии представлены следующие  поставщики тепличных комплексов:

1. ЮВИС, ООО, торговая компания;

2. Производственная компания, ИП  Влотников И.И.

3. Завод МЕТАЛЛ-СЕРВИС

Максимум автоматизации этих теплиц представляет собой включение выключения света при помощи простейшего реле или, как в случае завода МЕТАЛЛ-СЕРВИС, автоматическое открытие форточки.

Интеллектуальное комплексное  управление выращиванием продукции  по циклу отсутствует.

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

Пример: ЗАО "Курскпромтеплица" производит металлоконструкции современных  зимних блочных и пленочных теплиц, систем зашторивания и отопления, осуществляет полный цикл услуг в области инжиниринговых, проектно-изыскательских, инженерно-консультационных работ, организации и осуществлению комплекса работ по строительству объектов «под ключ», включая строительно-монтажные, пуско-наладочные, шеф-монтажные работы и агротехнологическое сопровождение проектов.

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

 

 

 

 

 

 

 

 

 

 

 

 

Выводы:

1. В ходе изучения предметной области – была проанализирован процесс интенсивного выращивания растений в теплице и доказана необходимость его автоматизации.
2. Исходя из основных требований к процессу выращивания растений , были разработаны требования к программному продукту.
3. Были проанализированы существующие системы автоматизации, выявлены их недостатки, доказано их несоответствие задачам автоматизации процесса выращивания.
 

2. ПрОектирование программного продукта

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

2.1.Выбор методологии  проектирования и модели жизненного  цикла программного продукта

Каскадная модель — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки (Рис.2.1).

Рис.2.1.Каскадная модель жизненного цикла

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

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

V-Model (или VEE модель) является моделью  разработки информационных систем (ИС), направленной на упрощение  понимания сложностей, связанных  с разработкой систем. Она используется  для определения единой процедуры разработки программных продуктов, аппаратного обеспечения и человеко-машинных интерфейсов (Рис.2.2).

Рис.2.2 V - модель жизненного цикла

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

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

Спиральная модель - представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование (Рис.2.3).

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

• оценка и разрешение рисков,
• определение целей,
• разработка и тестирование,
• планирование.

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

Для того чтобы наглядно показать принцип работы программного продукта могут быть использованы графические  материалы, например  DFD – диаграммы. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, данные структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

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

 Одним из возможных подходов  к разработке программного обеспечения  в рамках спиральной модели  жизненного цикла является получившая  в последнее время широкое  распространение методология быстрой  разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

• небольшую команду программистов (от 2 до 10 человек);
• короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
• повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:

• фаза определения требований и анализа;
• фаза проектирования;
• фаза реализации;
• фаза внедрения.

Рис.2.3 Спиральная модель жизненного цикла

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

Обоснование выбора:

• Методологию RAD целесообразно использовать при небольшой команде разработчиков и сжатых сроках выполнения работы;
• Повторяющийся цикл разработки позволяет наиболее точно реализовать все требования заказчика, благодаря тесному взаимодействию разработчика с заказчиком;
• DFD – диаграммы обеспечивают наиболее полное и понятное описание взаимодействия отдельных модулей ПП;
• Спиральная модель жизненного позволяет изменять ПП в соответствии с изменяющимися требованиями заказчика.

2.2. Архитектура программного  продукта

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

Серверная часть выполняет следующие  функции:

• Прием и обработка информации, поступающей от теплицы (усредненные данные с датчиков и состояние системы);
• Хранение поступающей информации в базе данных;
• Взаимодействие с клиентским программным обеспечением;
• Слежение за показателями системы в режиме реального времени и оповещение в случае критических событий. Система оповещения сигнализирует о событии путем передачи сообщения о событии на клиентское программное обеспечение, отправки SMS-сообщения, отправки письма на электронную почту обслуживающего персонала;
• Передача команд нижнему уровню (включение\отключение полива, освещения, вентиляции, обогрева);
• Хранение и передача оптимальных значений для каждого из этапов жизненного цикла культуры на нижний уровень для выполнения автоматической корректировки параметров среды (максимальная и минимальная температура, влажность и т.д.);

Функции клиентской части:

• Взаимодействие с серверной частью (запрос данных с сервера, передача команд);
• Визуализация данных;
• Подача звукового сигнала, отображения сообщения на экране клиентского устройства при получении сообщения о критическом событии;
• Экспорт журнала событий в Microsoft Excel или в формат XML для последующей обработки и анализа.

Клиентская и серверная части  взаимодействуют друг с другом через  локальную сеть или сеть Интернет. Такая архитектура обеспечивает наиболее эффективное взаимодействие системы с клиентом (рис.2.1).

2.3. Логическая модель

Логическая модель проекта описывается  с помощью DFD – диаграмм. Представлены два уровня диаграмм с разным уровнем детализации (рис. 2.2., 2.3). Первый уровень показывает обмен информацией между разрабатываемым ПП и автоматизированной теплицей, второй – обмен информацией между 3 основными модулями системы.

 

Рис.2.1 Архитектура ПП

 

Рис.2.2 DFD - диаграмма 1-го уровня