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

  • Вид работы:
    Дипломная (ВКР)
  • Предмет:
    Информационное обеспечение, программирование
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    3,8 Мб
  • Опубликовано:
    2013-11-19
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

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

Введение


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

Автоматизированные системы управления в настоящее время широко используются во всех звеньях управления народным хозяйством. ГОСТ 24.003-84 следующим образом определяет АСУ: «Автоматизированная система управления - система «человек - машина», обеспечивающая эффективное функционирование объекта, в которой сбор и переработка информации, необходимой для реализации функций управления, осуществляется с применением средств автоматизации и вычислительной техники».

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

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

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

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

1. Исследование предметной области

 

.1 Анализ предметной области


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

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

Все эти обстоятельства предопределяют высокие требования к функционированию и качественному совершенствованию оборудования автоматизации.

Представим объект управления (теплицу) в виде черного ящика рисунок 1.1; выходные величины которого указаны справа (температура, влажность, освещенность внутри теплицы).

Управляемые величины на рисунке 1.1 изображены сверху. К ним относятся параметры теплоносителя. Контролируемые факторы на рисунке изображены слева.

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

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

Рисунок 1.1 - Теплица как объект управления (биологический и технический)

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

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

1.2 Концептуальное моделирование предметной области


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

Рисунок 1.2 - Разбиение проектируемой системы на слои

Пользовательский интерфейс представляет собой коммуникативное средство между пользователем и всей системой в целом. Планируется разработка пользовательского интерфейса с использованием передовых технологий Microsoft Windows Presentation Foundation, что позволит легко в дальнейшем легко расширять, поддерживать и модифицировать.

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

Доступ к данным - на этом слои используется разработанный корпорацией Microsoft набор библиотек Entity Framework 5.0, что позволит существенно сократить время на разработку и повысить производительность программного продукта.

В качестве СУБД планируется использовать Microsoft SQL Server.

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

Аппаратная платформа будет представлять собой контроллер Arduino, как основной сегмент и различные датчики, реле, сервоприводы и ИК-контроллеры.

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

Разработка диаграммы вариантов использования преследует следующие цели:

-       Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы

-       Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

Средства Microsoft Visual Studio 2012 Enterprise Edition позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (рисунок 1.3, рисунок 1.4).

Рисунок 1.3 - Диаграмма вариантов использования для администратора

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

Рисунок 1.4 - Диаграмма вариантов использования для пользователя

Как видно на рисунках существует два типа конечных пользователей:

.        Администратор.

.        Пользователь.

Далее будут подробнее описаны функции каждого из них.

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

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

Рисунок 1.5 - Диаграмма последовательности

Диаграмма последовательности (рисунок 1.5) - диаграмма <#"656466.files/image006.gif">

Рисунок 1.6 - Диаграмма деятельности аппаратной части

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

Рисунок 1.7 - Диаграмма деятельности программной части

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

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

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

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

Диаграмма классов для обработки данных приведена на рисунке 1.8.

Рисунок 1.8 - Диаграмма классов для обработки данных

Диаграмма классов для взаимодействия с аппаратной платформой приведена на рисунке 1.9.

Рисунок 1.9 - Диаграмма классов для обработки данных

2. Анализ требований к разработке

 

.1 Требования к системе


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

При этом, чтобы изменить температуру внутри теплицы, требуется определенное время, пока горячая вода в трубах обогрева полностью заменит холодную и поднимет температуру в помещении. Таким образом, система регулирования микроклимата должна на основе алгоритмов прогнозирования заранее отдавать команды инженерным системам комплекса: системе обогрева, проветривания, зашторивания, испарительного охлаждения и электрического досвечивания. Кроме того, требования к точности поддержания параметров микроклимата данной теплицы достаточно высоки - в пределах 0,5 градуса Цельсия.

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

–  Стоимость системы управления. Этот фактор всегда учитывается в первую очередь и, зачастую, является решающим. Автоматизированные системы управления состоят из интеллектуальной, силовой и вспомогательной частей. Это:

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

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

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

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

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

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

–       Возможность обеспечения взаимосогласованного управления различными технологическими системами и исполнительными механизмами;

–       Качество поддержания требуемого климата в теплицах или возможность имеющимися средствами добиться минимального отклонения от задания поддерживаемых климатических параметров: температуры, влажности, концентрации СО2, освещённости;

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

–       Возможность согласованного с потребностями теплицы управления вспомогательными тепловыми пунктами, электрогенерирующими установками и энергосберегающими системами.

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

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

Степень автоматизации функций управления. Чем выше степень автоматизации, тем меньше требуется вмешательств оператора в процессы управления. В идеале, агроному требуется задать название сорта посаженной культуры и все действия по управлению исполнительными механизмами для обеспечения необходимого климата сделает система автоматического управления. Реально, на практике, агрономом или оператором, по указанию агронома, задаются задающие графики поддержания микроклимата и режимы работы оборудования, которые автоматически корректируются в соответствии с процессами управления, состоянием растений и внешними метеоусловиями. Системы, в которых аргоном, как великий «гуру», постоянно колдует над процентами открытия форточек или градусами теплоносителя - слабые системы, требующие постоянного и квалифицированного вмешательства в работу системы. Сильные системы на основе задания параметров микроклимата и введённых ограничений сами определяют необходимые режимы функционирования технологических систем и обеспечивают их корректировку в соответствии с автоматически контролируемыми процессами работы оборудования и состоянием растений в теплицах, создавая объективные предпосылки для надёжного повышения урожайности и качества урожая. Методы автоматического управления. Теплицы с множеством параметров, перекрёстных влияний, распределённостью на значительных площадях, изнашивающимся оборудованием, подверженностью непредсказуемым, а иногда и неизмеряемым, воздействиям относятся к классу сложных, многомерных, распределённых, нелинейных и нестационарных объектов управления. Методы управления должны быть соответствующие: оптимальные - обеспечивающие оптимизацию критерия качества, многосвязные - учитывающие многомерность объекта, динамические - учитывающие протяжённость процессов управления во времени, адаптивные и самообучающиеся - учитывающие нелинейность и изменяемость параметров объекта управления, с обратной связью по управлению и возмущениям. Традиционные ПИД-регуляторы, ситуационные регуляторы или балансные системы управления работают лишь в ограниченных диапазонах и условиях. Наилучшие результаты по качеству процессов управления обеспечивают системы, построенные на основе динамического моделирования процессов управления в теплицах. Причём, чем больше параметров учитывает используемая модель, тем точнее вычисляются процессы в теплицах и точнее определяются команды управления. Это относится как к процессам формирования микроклимата в теплицах, создающим условия для роста растений, так и к процессам самого роста растений. Степень автоматизации и применяемые в системах управления методы накладывают определённые требования на техническое обеспечение и, естественно, существенно влияют на стоимость систем управления. Поэтому, если к системам управления для промышленных тепличных комбинатов экономически целесообразно предъявлять максимальные требования, то к системам управления для средних (фермерских) и, тем более, для малых (индивидуальных) теплиц требования должны быть значительно ограничены.

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

–       Структура системы управления - количество уровней управления, централизованность или распределённость технических средств, структура сети передачи данных;

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

–       Наличие запаса по функциональным и количественным показателям;

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

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

 

.2 Анализ существующих разработок


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

Рисунок 2.1 - Схема интеграции SCADA-приложений в комплексные системы управления

Не смотря на большое разнообразие SCADA систем на рынке, большинство из них имеет примерно одинаковый набор функциональных возможностей позволяющих выполнять основные требования, предъявляемые к верхнему уровню АСУ ТП. Набор стандартных функций в SCADA системах обусловлен общим кругом задач при разработке систем автоматизации. Определим состав основных функций позволяющих выполнить полноценный проект по автоматизации:

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

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

.        Упрощенный язык составления алгоритмов управления ТП, математических вычислений.

.        Драйвера устройств и оборудования согласованной работы со SCADA системой, находящихся на нижнем и среднем уровнях АСУ ТП, такие как датчики, вторичное оборудование контроллеры.

.        Поддержка других языков программирования высокого уровня (Visual C++, VBA, VB).

.        И одна из важнейших функций SCADA систем - средства защиты от несанкционированного доступа к файлам и компонентам.

Далее будет приведён сравнительный анализ популярных и доступных на данный момент SCADA систем.SCADA - система визуализации АСУТП, MES, задач учета и диспетчеризации объектов промышленности, ЖКХ и зданий. Для оценки возможностей SCADA системы существует ознакомительная бесплатная версия на 32 точки и учебник по созданию АСУ ТП. Из других функций Master SCADA доступны следующие возможности:

–       взаимодействие с другими программами с помощью современных технологий (OPC, OLE, DCOM, ActiveX, OLE DB, ODBC и др.);

–       функция использования в операторской панели АСУ ТП документов любого типа и поддержка обмена данными с ними Master SCADA имеет неограниченное расширение функциональности за счет использования продуктов сторонних разработчиков;

–       наличие открытого интерфейса для создания пользователем любых базовых элементов.MODE® - это первая интегрированная информационная система для управления промышленным производством, объединяющая в едином целом продукты класса SOFTLOGIC-SCADA / HMI-MES-EAM-HRM. SCADA система TRACE MODE разработана в 1992 году и к настоящему времени имеет более 7000 внедрений на объектах АСУ ТП. На данный момент актуальной версией является SCADA система TRACE MODE® 6.

Проекты, разработанные на базе TRACE MODE, имеют инсталляции в энергетической, металлургической, атомной, нефтяной, газовой, химической, космической и других отраслях промышленности. Нашли применение при разработке АСДУ ЖКХ и сельском хозяйстве России.

В состав системы входят бесплатные драйверы для более чем 2-х тысяч контроллеров и УСО.

Для программирования алгоритмов управления технологическими процессами в SCADA системе TRACE MODE 6 поддержаны все 5 языков международного стандарта IEC 61131-3. Такие как - Techno FBD, Techno LD, Techno SFC и процедурные - Techno ST, Techno IL.

SIMP Light miniSCADA - реализованные в системе инновационные решения, позволяют максимально сократить сроки на разработку, настройку и дальнейшую эксплуатацию проектов по АСУ ТП. SCADA система не требует от разработчика специфических знаний в области программирования и разработки систем верхнего уровня. Достаточно только сконфигурировать систему под разрабатываемые задачи, имея лишь базовые знания пользователя ПК.Light miniSCADA имеет поддержку большого количеств моделей контроллеров и устройств сбора данных. Является одной из недорогих сред разработки визуализации.SCADA - программный продукт, представляющий собой полнофункциональную систему визуализации и мониторинга, управления и сбора данных. ПО Citect SCADA включает в себя все функциональные блоки (тренды, алармы, отчеты, драйвера, протоколы) представляя собой единое средство разработки проекта. В отличие от ПК -совместимых АСУ ТП Citect SCADA разрабатывалась как высокоэффективное средство управления интегрированными системами предприятия. Технологии Internet Explorer’а позволяют реализовывать удаленный мониторинг системы и управление технологическим процессом.

Дополнительное расширение возможностей Citect SCADA:

–       CitectFacilities - специальное приложение для автоматизации зданий и систем жизнеобеспечения сооружений и объектов ЖКХ.

–       CitectSCADA Reports - Мощная система сбора данных и генерации отчетов на основе MS SQL Server 2008 и встроенной службы Reporting Services.система PcVue - полнофункциональный продукт для решения задач распределенного мониторинга и управления. Интеллектуальный Генератор (Smart Generator) создает приложения PcVue из различных программных продуктов, включая AutoCad, CoDeSys и ISaGRAF. В совокупности с компонентом WebVue PcVue предлагает решение для детальной настройки, которая доступна из обычного Web-браузера через интранет или Интернет. Система поддерживает возможность расширения за счет добавления модулей и средств для того.

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

3. Техническое задание на разработку программно-аппаратного комплекса


Наименование программно-аппаратного комплекса: "Eco SCADA теплица".

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

-  Сведения о пользователях системы.

-       Сведения о теплицах.

-       Сведения об аппаратных контроллерах и датчиках.

-       Сведения о состоянии показателей.

Программа предоставляет оконный интерфейс для управления базой данных и аппаратным контроллером в соответствии с предъявляемыми требованиями к эргономичности.

Программа должна обеспечивать возможность выполнения перечисленных ниже функций:

-  Разделение пользователей подключаемых через оконный интерфейс на группы:

-       Администраторы.

-       Пользователи.

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

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

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

-       Администратор должен иметь возможность проводить удалённую диагностику всех аппаратных подсистем.

-       Для Администраторов базы данных возможность анализа в базе данных динамики изменения сведений о пользователях.

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

Надежное (устойчивое) функционирование программно-аппаратного комплекса должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

-  организацией бесперебойного питания технических средств;

-       использованием лицензионного программного обеспечения;

-       регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

-       регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.

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

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

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

Климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации

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

-  задача поддержания работоспособности технических средств;

-       задачи установки (инсталляции) и поддержания работоспособности системных программных средств - операционной системы;

-       задача установки (инсталляции) программы;

-       задача создания резервных копий базы данных.

В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:

-  процессор Pentium-2.8Hz, не менее;

-       оперативную память объемом, 2Гигабайт, не менее;

-       HDD, 60 Гигабайт, не менее;

-       серверную операционную систему Windows 2008 Server или Windows Server 2012;

-       операционную систему Windows Vista,Windows 7, Windows 8;

-       Microsoft SQL Server 2012 Standard или Enterprise Edition.

База данных работает под управлением Microsoft SQL Server 2012 Standard Edition. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных.

Аппаратные модули должны быть реализованы на базе контроллера Arduino серии Mega 2560 или совместимого с этим контроллера с 8-ми битным ядром ATMega 128 либо старше.

Пользователи и администраторы работают с базой данных через оконный интерфейс.

Администраторы системы должны иметь возможность редактировать таблицы (добавление, редактирование)

Исходный код программного продукта должен быть написан на ЯВУ C# и быть совместим с платформой .NET Framework 4.5. Исходный код прошивки аппаратной части написан на ЯВУ С.

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2008 Server или Windows Server 2012 и Microsoft SQL Server 2012 Standard Edition.

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

Состав программно-аппаратной документации должен включать в себя:

-    техническое задание;

-       программу и методики испытаний;

-       руководство по установке;

-       руководство администратор;

-       руководство пользователя;

-       руководство системного программиста.

Разработка должна быть проведена в три стадии:

.     разработка технического задания;

2.      рабочее проектирование;

.        внедрение.

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

.        разработка программно-аппаратного комплекса;

.        разработка программно-аппаратной документации;

.        испытания программно-аппаратного комплекса.

На стадии внедрения должен быть выполнен этап разработки подготовка и передача программно-аппаратного комплекса.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

.        постановка задачи;

.        определение и уточнение требований к техническим средствам;

.        определение требований к программно-аппаратному комплексу;

.        определение стадий, этапов и сроков разработки программно-аппаратного комплекса и документации на него;

.        согласование и утверждение технического задания.

На этапе разработки программно-аппаратного комплекса должна быть выполнена работа по конструированию, макетированию, созданию прошивки и программированию (кодированию) и отладке программно-аппаратного комплекса.

На этапе разработки программно-аппаратной документации должна быть выполнена разработка программно-аппаратных документов в соответствии с требованиями к составу документации.

На этапе испытаний программно-аппаратного комплекса должны быть выполнены перечисленные ниже виды работ:

.        разработка, согласование и утверждение и методики испытаний;

.        проведение приемо-сдаточных испытаний;

.        корректировка программно-аппаратного комплекса и программно-аппаратной документации по результатам испытаний.

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

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки.

Приемо-сдаточные испытания программно-аппаратного комплекса должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком программы и методик испытаний.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

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

база данные информационный поток

4. Выбор средств разработки программного обеспечения

 

.1 Обоснование выбора средств моделирования


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

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

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

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

Этот пакет предназначен исключительно для рисования диаграмм. Visio не является средством моделирования, это программа для создания иллюстраций с возможностью построения UML-диаграмм (рисунок 4.1).

Рисунок 4.1 - Microsoft Visio

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

Этот динамичный и универсальный инструмент облегчает анализ, проектирование и разработку объектно-ориентированных программ и баз данных. Поддерживает Java, C++, C#, CL(MSIL) и CORBA IDL (рисунок 4.2).

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

Продукт развивается с 1998 года, компания No Magic предлагает удобные механизмы лицензирования MagicDraw UML.

Доступны персональные лицензии и лицензии на количество подключений к серверу совместной разработки. Гибкая политика позволяет приобретать лицензии со скидкой. Также компания организует различные курсы по обучению групп пользователей. Существует несколько версий: Reader, Personal, Standard, Professional, Architect и Enterprise.

Версия MagicDraw UML Reader бесплатная, она создана для просмотра созданных моделей.

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

Версия MagicDraw Personal содержит полный функционал моделирования диаграмм UML 2.3, базовые отчеты и экспорт диаграмм как изображений.

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

Версия MagicDraw Standard включает в себя весь функционал версии Personal и дополнительные возможности создания моделей пользовательского интерфейса, матриц зависимостей, карт связей и отношений, диаграмм содержания, интеграцию с популярными средами разработки (Eclipse, Netbeans и т.д.).

Включена полная поддержка диаграмм бизнес процессов BPMN 2.0, этот вид диаграмм удобен и понятен как бизнес пользователям, так и IT пользователям.

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

Версия Enterprise представляет собой наиболее полную сборку MagicDraw UML и покрывает все аспекты моделирования, анализа, проектирования и разработки отраженные в моделях UML.

Рисунок 4.2 - No Magic MagicDraw UML

PowerDesigner - полнофункциональный инструментарий для создания бизнес-приложений, включающий в себя средства моделирования бизнес-процессов, возможности концептуального и физического проектирования баз данных, возможности моделирования с использованием UML и предоставляющий централизованный репозиторий для хранения моделей и объектов (рисунок 4.3).Rational Rose - CASE-средство для проектирования программных систем любой сложности.Rose используется для решения задач проектирования информационных систем - от анализа бизнес-процессов до кодогенерации на определенном языке программирования, что позволяет не только спроектировать новую систему, но и доработать старую, произведя процесс обратного проектирования [2].Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели и тем самым осуществлять либо абстрактное, либо логическое проектирование (рисунок 4.4).

Рисунок 4.3 - Sybase PowerDesigner

Рисунок 4.4 - IBM Rational Rose

CASE-средства сравнивались по следующим критериям (см. таблицу 4.1) с оценками от 0 до 10:

Таблица 4.1 - Оценка средств моделирования

Критерий

Visio

MagicDraw

Sybase PowerCenter

Rational Rose

MS Visual Studio 2012

Поддержка UML

8

10

10

10

10

Проверка правильности UML-диаграмм

0

10

10

8

10

Кодогенерация на основе диаграмм

0

10

10

10

10

Реверсивный инжиниринг исходных кодов

0

10

10

10

10

Поддержка процессов разработки

7

8

8

10

10

Проектирование БД

8

10

10

10

10

Поддерживаемые БД, по умолчанию

5

5

5

5

10

Проверка правильности БД

6

10

9

10

10

Реверсивный инжиниринг БД

7

10

9

10

10

Эффективность использования (юзабилити)

7

9

10

9

9

Итого

48

92

91

92

99


На основании приведённых выше данных можно сделать вывод, что наилучшим средством моделирования для данного проекта является Microsoft Visual Studio 2012. Кроме технических показателей принимаются в расчёт и экономические показатели т.к. для разработки программной части потребуется Microsoft Visual Studio, то тем более не стоит выбирать другой продукт для моделирования т.к. это увеличит затраты на разработку.

 

.2 Обоснование выбора системы управления базами данных


Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды.- это крупнейшая фирма-разработчик баз данных для Windows NT и UNIX. Oracle создала собственный набор инструментов (в основном это PL / SQL в сочетании с Oracle Web Agent ). Эти средства в комплексе с Web -сервером Oracle облегчают создание Web -страниц с использованием информации, которая хранится в базе данных. Процедура PL / SQL позволяет ускорить запрос к базе данных. СУБД Oracle подходит для крупного предприятия, где требуется обрабатывать большое количество информации, однако стоимость сегодня Oracle 11 и Web -сервера Oracle вместе составляет более 5000$.

Sybase System 12 представляет собой базу данных, в которой имеются средства для создания динамических Web -страниц. Sybase в сочетании с Net Impact Studio (продуктом фирмы Power soft ) можно использовать создания богатого набора инструментов, с помощью которых можно создавать документы динамического HTML. Net Impact Studio состоит из браузера/редактора HTML и персонального Web -сервера. Эти средства позволяют создать Web -страницы с использованием технологии WYSIWYG.

Кроме того, в комплект Net Impact Studio входит база данных Web , поддержка JavaScript и поддержка подключения к серверам приложений.Impact можно использовать в сочетании с Power Builder - приложением, которое служит для создания модулей-приложений и компонентов ActivX. Его также можно использовать как дополнение к Optima++, которая предназначена для создания модулей и облегчает создание аплетов Java. Кроме того, Sybase можно использовать с Web Sql для создания приложений CGI и программного интерфейса NSAPI ( Netscape Server Application Programming Interfase ), которые обращаются к серверу базы данных Sybase на языке Perl. Sybase подходит для систем Windows NT и UNIX.

Фирма Microsoft недавно обновила версию сервера базы данных Microsoft SQL Server 2012. Microsoft пытается конкурировать в этой области с Oracle, IBM и Sybase. Сервер Microsoft стоит примерно 1000$, но, кроме того, вам придется приобрести еще и SQL Server Internet Connector, который стоит около 3000$. Эти два продукта позволяют создать неограниченный доступ к серверу из Web.Access - это система управления реляционными базами данных. Которая входит в комплект Microsoft Office. Microsoft Access можно использовать для создания документов HTML, основанных на информации, которая хранится в базе данных Access с помощью Microsoft Internet Assistant или Microsoft Active Server Pages.NET (ASP.NET). Microsoft Internet Assistant это надстройка, предоставляемая бесплатно пользователям Access. Использование технологий ASP.NET требует наличия MS Information Server с инсталлированным ASP.NET. База данных Microsoft Access может поддерживать элементы управления ActivX, что делает Access еще более мощным средством при использовании вместе с Microsoft Internet Explorer.

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

Для принятия окончательно решения построена таблицу 4.2 с основными характеристиками СУБД.

Таблица 4.2 - Сравнение СУБД

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

Базы данных

Платформа

Рекомендуемое использование

Oracle

Windows NT и UNIX

Крупные предприятия

Sybase

Windows NT и UNIX

Крупные предприятия

Microsoft SQL

Windows NT

Крупные и средние предприятия

Microsoft Access

Windows NT

Личное использование, мелкие и средние предприятия


На основании приведённого выше описания и таблицы сравнений было принято решение об использование в качестве СУБД Microsoft SQL Server 2012.

 

.3 Обоснование выбора среды разработки программной части


Анализ среды MonoDevelop представленной на рисунке 4.5. Пользовательский интерфейс четко продуман.

Программа отличается высоким быстродействием и проста в освоении.

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

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

Имеется окно Solution, в котором показаны все файлы, входящие в ваш проект, есть также полноценный отладчик, предоставляющий стандартные средства типа точек останова и инспекторов контроля состояния.

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

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

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

Рисунок 4.5 - Среда разработки MonoDevelop

Microsoft Visual Studio (рисунок 4.6)- линейка продуктов компании Майкрософт <#"656466.files/image016.gif">

Рисунок 4.6 - Среда разработки Microsoft Visual Studio 2012

На основе приведённых выше обзоров была выбрана для разработки программное обеспечение компании Microsoft, потому что оно наиболее полно удовлетворяет потребностям в разработке, а также отвечает всем современным стандартам разработки программного обеспечения и включает множество инструментов для моделирования, отладки и тестирования разработанного программного кода. Также используя дополнение Visual Micro в среде Microsoft Visual Studio 2012 можно разрабатывать и отлаживать код для прошивки микроконтроллеров, что потребуется при разработке аппаратной части проекта.

 

.4 Обоснование выбора среды разработки аппаратной части


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

Пакет PROTEUS представленный на рисунке 4.7 представляет собой систему схемотехнического моделирования, базирующуюся на основе моделей электронных компонентов принятых в PSpice <#"656466.files/image017.gif">

Рисунок 4.7 - Пакет Proteus

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

-  Altium Designer Custom Board Front-End Design - Проектирование ПЛИС, схемотехническое проектирование и моделирование.

-       Altium Designer Custom Board Implementation - Проектирование печатных плат и ПЛИС.

В состав программного комплекса Altium Designer представленный на рисунке 4.8, входит весь необходимый инструментарий для разработки, редактирования и отладки проектов на базе электрических схем и ПЛИС. Редактор схем позволяет вводить многоиерархические и многоканальные схемы любой сложности, а также проводить смешанное цифро-аналоговое моделирование. Библиотеки программы содержат более 90 тысяч готовых компонентов, у многих из которых имеются модели посадочных мест, SPICE <#"656466.files/image018.gif">

Рисунок 4.8 - Altium Designer

Дальнейшее рассмотрение программных продуктов не имеет смысла т.к. только приведённые в обзоре выше два продукта имеют необходимый функционал для предварительной отладки программных кодов прошивки микроконтроллера в виртуальной среде. Для данного проекта была выбрана Proteus потому что он полностью удовлетворяет всем требованиям для разработки и к тому же является менее тяжеловесным и дорогим чем Altium Designer.

5. Основная часть

 

.1 Архитектура работы с базой данных


Объектная и реляционная модели ортогональны. Это значит, что они моделируют одну и ту же сущность, но с разных сторон, под разными, как бы перпендикулярными углами зрения. Реляционная модель акцентирует свое внимание на структуре и связях сущностей, объектная - на их свойствах и поведении. Цель использования реляционной модели - информационное моделирование, выделение существенных для нас атрибутов, сохранение их значений и последующего поиска, обработки и анализа. Цель использования объектной - моделирование поведения, выделение существенных для нас функций и последующего их использования. Между моделями есть пересечение - структурные сущности, которые по-разному в этих моделях отражаются. Для того, чтобы отобразить артефакты реляционной модели в артефакты же объектной в наших программах и требуется средство объектно-реляционной проекции - ОРПили широко распространенное англоязычное обозначение - ORM (Object Relational Mapping).

Объектно-реляционный проектор - ОРП - теоретически позволяет программисту работать с таблицами, полями и связями реляционной БД, как с объектами, свойствами и коллекциями (массивами), не отвлекаясь на подробности более низкого уровня, такими, например, как порядок выборки и сохранения модифицированных данных, вопросы переносимости и особенностей диалекта SQL конкретной СУБД, генерации уникальных первичных ключей, заполнения полей ссылок для моделирования связей.

Для решения поставленных задач был проведён сравнительный анализ существующих ORM для платформы .NET, детальный анализ приведён ниже. Для проведения анализа воспользовавшись стандартной базой данных Northwind и с использованием этой базы провёл ряд тестов описанных в таблице 5.1.

Таблица 5.1 - Тестирование ORM

Тест

Описание

Цель

Инициализация

Создание контекста, инициализация, чтение строки подключения

Получить время инициализации, возможно, оптимизировать его

Получение всех заказов

Простая выборка всех строк из таблицы Orders

Самый простой запрос, в то же время можно сравнить время материализации, т.к. там больше 800 записей

Многократное получение всех заказов

Выборка всех строк из таблицы Orders 3 раза

Получение всех продуктов одного заказчика

Один сложный запрос через 3 таблицы

Сравнить эффективность генерацииSQL-скриптов, материализация минимальна

Многократное получение всех продуктов одного заказчика

Тот же запрос 3 раза

То же самое + кеширование

Получение всех продуктов одного заказчика (сложная версия)

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

Сравнить данный способ обращения к данным с предыдущим

Многократное получение всех продуктов одного заказчика (сложная версия)

То же самое 3 раза

То же самое + кеширование

Микс: получение заказов + продуктов заказчика

Синтетический тест, эмулирующий разные запросы

Посмотреть, как влияют результаты выполнения одного запроса на следующий

Тест более серьезной нагрузкой

Все предыдущие запросы последовательно за один присест

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


Таблица 5.3 - Описание NHibernate

Название

NHibernate

Производитель, сайт

<#"656466.files/image019.gif">

Рисунок 5.3 - Структура базы данных

Таблица 5.8 - Описание таблицы dbo.GreenhouseStat

Имя поля

Тип данных

Определение поля

Id

int

Уникальный идентификатор

GreenhouseId

int

Идентификатор теплицы

Date

smalldatetime

Дата и время записи

Temperature

float

Текущая температура

Humadity

float

Текущая влажность

Status

nvarchar(25)

Статус системы


Таблица 5.9 - Описание таблицы dbo.Controller

Имя поля

Тип данных

Определение поля

Id

int

Уникальный идентификатор

Type

nvarchar(50)

Тип контроллера

Port

nvarchar(50)

Порт для связи

IsComPort

bit

Определение типа связи COM или IP

GreenhouseId

int

Идентификатор теплицы

State

int

Статус


Описание таблиц приведённое выше даёт детальное представление о всей структуре хранимых данных, а также о типах данных используемых при хранение основных показателей и основных настроек всего программно-аппаратного комплекса.

 

.3 Реализация слоя доступа к данным


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

.        Вставка.

.        Редактирование.

.        Удаление.

На рисунке 5.4 приведена схема взаимосвязи классов, реализующих доступ к данным с внешними сборками входящими в стандартную поставку Microsoft .NET Framework 4.5. Также на этой схеме изображены взаимосвязи классов между собой, а именно использование одних классах в других. Детальная структура классов приведена на рисунке 5.5 с отображением всех полей и методов, которые реализуют классы для доступа к данным.

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

Рисунок 5.4 - Взаимосвязь классов между собой

5.4 Разработка аппаратного модуля


Для реализации проекта необходимо разработать не только программную но и аппаратную часть. В качестве базовой платформы для разработки аппаратной части была выбрана платформа Arduino по причине её доступности цены и модульности. Для реализации прошивки используется ЯВУ С с набором библиотек входящих в поставку ArduinoIDE.

Рисунок 5.5 - Диаграмма классов для модуля доступа к данным

Далее приведён минимальный набор компонентов необходимый для обеспечения автоматизации одной теплицы:

1.      Arduino Mega 2560

.        Датчик DHT22

.        Релейный модуль

.        Запорный клапан

.        Сервопривод.

Arduino Mega построена на микроконтроллере ATmega2560. Плата имеет 54 цифровых входа/выходов (14 из которых могут использоваться как выходы ШИМ), 16 аналоговых входов,4 последовательных порта UART, кварцевый генератор 16 МГц, USB коннектор, разъем питания, разъем ICSP и кнопка перезагрузки. Для работы необходимо подключить платформу к компьютеру посредством кабеля USB или подать питание при помощи адаптера AC/DC, или аккумуляторной батареей. Arduino Mega 2560 совместима со всеми платами расширения, разработанными для платформ Uno <#"656466.files/image022.gif">

Рисунок 5.10 - Принципиальная схема подключения

6. Реализация разработки

 

.1 Разработка программных интерфейсов


Разработка программных интерфейсов и классов состоит из двух основных частей:

–       Система взаимодействия с аппаратным обеспечением.

–       Система взаимодействия с пользователем.

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

Рисунок 6.1 - Базовые классы для взаимодействия с аппаратной платформой

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

Непосредственно для взаимодействия с контроллером создан отдельный класс, диаграмма которого представлена на рисунке 6.2 вместе со вспомогательными классами и фабриками.

Рисунок 6.2 - диаграмма классов управления Arduino

Протокол взаимодействия представлен на рисунке 6.3. Он состоит из следующей последовательности:

1.   Размер посылки (1 байт).

2.      Тип устройства (1 байт).

.        Код команды (1 байт).

.        Флаг наличия адреса (1 байт).

.        Адрес (8 байт).

.        Дополнительные параметры (до 243 байт).

Рисунок 6.3 - графическое представление протокола обмена

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

Визуализируемый пользователю программный модуль строится на шаблоне MVVM. Соответственно представление отделено от данных для этого используются две разные сборки классов и третья сборка осуществляющая основную компоновку интерфейса и вызов нужных модулей - оболочка:

–  EcoProduct.Models - модели данных.

–       EcoProduct.Modules - визуальное представление.

–       EcoProduct.Shell - основная оболочка.

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

Рисунок 6.4 - Диаграмма взаимосвязи сборок и классов

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

Рисунок 6.5 - Диаграмма класса модели данных

 

.2 Разработка пользовательских интерфейсов


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

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

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

–       минимального объёма оперативной памяти пользователя. От ЧО требуется, чтобы он запоминал минимум информации как текущей, так и общей. Поскольку скорость переработки информации оператором и его пропускная способность существенно ограничены.

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

–       учёт профессиональных навыков пользователя.

Для реализации всех описанных выше требований и принципов мною было принято решение использовать технологию Windows Presentation Foundation от Microsoft. Преимущества данной технологии расписаны далее.

Windows Presentation Foundation (WPF) - система для построения клиентских приложений Windows <#"656466.files/image028.gif">

Рисунок 7.1 - Вход в программу

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

Рисунок 7.2 - Главное окно

Для управления пользователями администратору необходимо нажать кнопку «Пользователи», после чего откроется окно управления пользователями изображенное на рисунке 7.3.

Рисунок 7.3 - Управление пользователями

Для создания пользователя необходимо нажать кнопку «Добавить» в панели управления, после этого откроется окно изображенное на рисунке 7.4.

Рисунок 7.4 - Добавление пользователя

Для редактирования информации о пользователе, необходимо выбрать пользователя в таблице и нажать кнопку «Редактировать», после этого откроется окно показанное на рисунке 7.5.

Рисунок 7.5 - Редактирование пользователя

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

Рисунок 7.6 - Подтверждение удаления пользователя

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

Рисунок 7.7 - Отображение сведений о теплицах

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

Рисунок 7.8 - Добавление данных о теплице

Для редактирования информации о теплице, необходимо выбрать теплицу в таблице и нажать кнопку «Редактировать», после этого откроется окно показанное на рисунке 7.9.

Рисунок 7.9 - Редактирование данных о теплице

Для предотвращения ошибок при попытке удаления теплицы появляется окно с подтверждением действия (рисунок 7.10), лишь после подтверждения теплица удаляется.

Рисунок 7.10 - Подтверждение удаления теплицы

Управление контроллерами осуществляется аналогично управлению теплицами, в строгом соответствии с моделями данных.

 

.3 Руководство программиста


Данное руководство предназначено для разработчиков структура руководства приведена на рисунке 7.11.

Рисунок 7.11 - Структура руководства программиста

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

Здесь будет рассмотрен пример на основе модуля управления контроллерами (рисунок 7.12) полное руководство разработчика представлено виде приложения на компакт диске.

Рисунок 7.12 -Пример руководства программиста

Весь код имеет детальные комментарии, пример комментариев приведён ниже.

/// <summary>

/// Добавление сведений о контроллере.

/// </summary>

/// <param name="item">Обект контроллера который необходимо добавить <seealso cref="Controller"/>.</param>

/// <returns>Идентификатор созданного контроллера.</returns>

public int AddController(Controller item)

{.Controller.Add(item);.SaveChanges();

return item.Id;

}

7.4 Руководство системного программиста


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

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

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

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

//Номера в последовательности коммандного массива

#define DEVICE_CODE                 0x00

#define COMMAND_CODE 0x01

//Управление устройства по ИК каналу

#define IR_CONTROLED               0x01

#define IR_PROTO_NEC                0x01

#define IR_PROTO_SONY             0x02

#define IR_PROTO_RC5                0x03

#define IR_PROTO_RC6                0x04

#define IR_PROTO_PANASONIC 0x05

#define IR_PROTO_JVC                0x06

#define IR_PROTO_SAMSUNG    0x07

#define IR_PROTO_RAW              0x08

//Датчик температуры Dallas

#define DS_TEMPERATURE_SENSOR_CODE                 0x03

#define DS_TEMPERATURE_GET_TEMPERATURE      0x01

#define TEMPERATURE_PRECISION 0x09

//Сенсор температуры и влажности

#define DHT_SENSOR_CODE                0x04

#define DHT_SENSOR_BASE_PIN        A0

#define DHT_SENSOR_ADRESS  0x02

#define DHT_GET_ALLDATA                0x01

#define DHT_GET_TEMPERATURE     0x02

#define DHT_GET_HUMIDITY     0x03

//Управление массивом реле через регистр

#define RELAY_CODE                            0x08

#define RELAY_INVERT_CODE  0x09

#define RELAY_ADRESS              0x03 // Смещение определяющее адрес реле

#define RELAY_ON                        0x01

#define RELAY_OFF                      0x02

#define RELAY_STATUS              0x03

#define RELAY_RESET                           0x04

#define RELAY_PIN_DS                0x28 //40

#define RELAY_PIN_SH                0x29 //41

#define RELAY_PIN_ST                0x2A //42

#define RELAY_INVERT_PIN_DS         0x2B //43

#define RELAY_INVERT_PIN_SH         0x2C //44

#define RELAY_INVERT_PIN_ST          0x2D //45

//Управление одним реле напрямую

#define PRIMARY_RELAY_CODE                           0x0A

#define PRIMARY_RELAY_INVERT_CODE  0x0B

#define PRIMARY_RELAY_PIN                      0x2E//46

#define PRIMARY_RELAY_INVERT_PIN      0x2F//47

//Порт шины OneWire

#define ONE_WIRE_BUS     0x01

//Размер буфера данных

#define MAX_DATA_BUFFER 64

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

 

.5 Руководство пользователя


Для запуска программы воспользуйтесь ярлыком на рабочем столе с названием «EcoProduct». После запуска программы откроется окно изображенное на рисунке 7.13, в котором Вам необходиммо ввести имя пользователя и пароль (по умолчанию логин: Пользователь, пароль:P@ssw0rd).

Рисунок 7.13 - Вход в программу

После успешного входа на экране отобразится главное окно (рисунок 7.14), в котором представлены статистические данные.

Рисунок 7.14- Главное окно программы

Эти данные можно сортировать и группировать по усмотрению пользователя (рисунок 7.15)

Рисунок 7.15 - Сортировка и группировка записей

В случае необходимости пользователь может осуществлять управление температурой и влажностью вручную выбрав в списке необходимую теплицу, для этого лучше применить фильтр и нажав соответствующие кнопки, для ввода параметров откроется отдельное диалоговое окно (рисунок 7.16 и 7.17)

Рисунок 7.16 - Установка температуры

Рисунок 7.17 - Установка влажности

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

Рисунок 7.18 - Пример отчета

8. Оценка эффективности программно-аппаратного продукта


Эффективность - одна из возможных характеристик качества системы, а именно ее характеристика с точки зрения соотношения затрат и результатов функционирования системы. В дальнейшем будем понимать под экономической эффективностью ПИ меру соотношения затрат и результатов функционирования ПИ. К основным показателям экономической эффективности относятся: экономический эффект, коэффициент экономической эффективности капитальных вложений, срок окупаемости капитальных вложений.

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

-    сокращение расхода машинного времени и других ресурсов на отладку и сдачу задач в эксплуатацию;

-       повышение технического уровня, качества и объемов вычислительных работ;

-       увеличение объемов и сокращение сроков переработки информации;

-       повышение коэффициента использования вычислительных ресурсов, средств подготовки и передачи информации;

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

-       снижение трудоемкости работ программистов при программировании прикладных задач с использованием новых ПИ в организации-потребителей ПИ;

-       снижение затрат на эксплуатационные материалы.

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

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

 

.1 Основные этапы проекта разработки программного обеспечения


Разработку программного обеспечения можно разделить на следующие этапы:

1.   анализ информационных потоков, разработка структуры таблиц базы данных, выбор CASE-средства для проектирования информационной системы и среды программирования;

2.      разработка программных модулей (программного обеспечения), разработка интерфейса, подготовка справочных баз данных;

.        тестирование, отладка и исправление недочетов: разработка методики проведения тестирования, отладка ПО, исправление ошибок и недочетов.

При разработке комплекса мероприятий по обучению персонала методам использования ПО, следует придерживаться следующей последовательности операций:

.     определение требований к пользователям ПО: разделение на группы пользователей (администратор, регистратор, лаборант и т.п.), описание совокупности предварительных навыков и умений, которыми должны обладать слушатели системы обучения;

2.      разработка перечня учебных курсов, формы их проведения (лекции, семинары, практические занятия и т.п.), длительности занятий (учебных часов);

.        расчет величины затрат на разработку учебно-методического обеспечения учебного процесса (затраты на разработку учебных пособий и их издание);

.        определение суммы затрат на реализацию системы обучения;

.        анализ затрат на переподготовку персонала для работы с ПО.

 

.2 Расчет трудоемкости проекта


Общие затраты труда на разработку и внедрение изделия (проекта) определяют следующим образом:

,                                                                         (8.1)

где ti - затраты труда на выполнение i - го этапа проекта.

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

Стоимость выставляемого на рынок ПО определяется частью стоимости разработки ПО, затрат на внедрение и прибыли фирмы-разработчика.

Для того, чтобы рассчитать стоимость ПО сначала следует определить частичную стоимость разработки, приходящаяся на каждый комплект ПО, которая определяется исходя из данных о планируемом объеме установок (8.2):

,                                                                      (8.2)

где К - стоимость проекта;

NOP - планируемое число копий ПО;

КСТ - ставка банковского процента по долгосрочным кредитам (более одного года).

Базовая ставка банковского процента равна 25% годовых. Подставив значения в формулу 8.3 получим частичную стоимость ПО равную 234 416 руб.

Программные продукты подобной функциональности стоят от 10 000 до 20 000 руб. Следовательно, целесообразно установить цену разрабатываемого продукта КПР равной 15 000 руб.

Стоимость ПО можно рассчитать, используя соотношение 8.3:

         ,                                              (8.3)

где DK - часть стоимости разработки, приходящаяся на одну копию программы;

КВН - стоимость внедрения программы;

DПРИБ - процент прибыли, заложенный в стоимость.

Подставив значения в формулу 6 получим стоимость ПО равную 251 386 руб.

Процент прибыли от одной реализации ПО определяется из соотношения 8.4:

                                                        (8.4)

С учетом данных о стоимости комплекта программы, стоимости установки и частичной стоимости разработки, процент прибыли от одной установки может составить (для данной разработки) 10.5%.

Сумма прибыли от продажи каждой установки ПО рассчитывается, используя следующее соотношение (8.5):

,                                                (8.5)

где ННДС - процентная ставка налога на добавочную стоимость.

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

9. Мероприятия по охране труда, безопасности жизнедеятельности


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

-  располагать рабочие места, оснащенные ПЭВМ и УВО, таким образом, чтобы естественный свет падал сбоку (с левой или правой стороны) в зависимости от расположения столов, оборудования и оконных проемов;

-       не допускать расположение рабочих мест с ПЭВМ и УВО в подвальных помещениях;

-       учитывать, что площадь на одно рабочее место с ПЭВМ и УВО должна составлять не менее 6,0 м2 , а объем - не менее 20,0 м3.

Не рекомендуется располагать рабочие места, оснащенные ПЭВМ и УВО, друг за другом. Задняя стенка монитора одного рабочего места не должна быть направлена на пользователя ПК, сидящего за другим рабочим местом.

Рабочий стол пользователя должен обеспечивать оптимальное расстояние элементов ПЭВМ. С этой целью столешница изготавливается как две раздельно регулируемые по высоте плоскости: одна - для размещения УВО, вторая - для размещения клавиатуры, пюпитра. Оптимальные размеры рабочей поверхности столешницы 1600 х 900 мм. С целью оптимального размещения ПЭВМ и УВО на рабочем месте можно рекомендовать увеличение площади столешницы за счет присоединения друг к другу двух столов или между двумя рабочими столами установить третий, более узкий. Это даст возможность оптимального размещения процессора, монитора и клавиатуры.

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

Рабочий стул (кресло) должен снабжаться подъемно-поворотным устройством, обеспечивающим регулировку высоты сиденья и спинки, его конструкция должна также предусматривать изменение угла наклона спинки. Рабочее кресло должно иметь подлокотники. Регулировка каждого параметра должна осуществляться легко, быть независимой и иметь надежную фиксацию. Высота поверхности сидения должна регулироваться в пределах 400-500 мм. Ширина и глубина сиденья должны составлять не менее 400 мм.

На рабочем месте необходимо предусматривать подставку для ног. Ее длина должна составлять 400 мм, ширина - 350 мм.

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

Кондиционирование воздуха должно обеспечивать автоматическое поддержание параметров микроклимата в необходимых пределах в течении всех сезонов года, очистку воздуха от пыли и вредных веществ. Необходимо также предусмотреть возможность индивидуальной регулировки подачи воздуха в отдельных помещениях. Температура воздуха, подаваемая в помещения с ПЭВМ и УВО, должна быть не ниже 19о С.

Мероприятия по снижению шума на рабочих местах, оснащенных ПЭВМ и УВО, должны включать организационные, строительно-акустические и другие мероприятия: устройство подвесных потолков, облицовка стен, ковровые покрытия. Звукопоглощающие материалы должны быть с максимальным коэффициентом звукопоглощения в диапазоне частот 63-8000 Гц.

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

-  ПЭВМ и УВО следует располагать при однорядном их размещении на расстоянии не менее 1 м от стен; рабочие места с мониторами должны располагаться между собой на расстоянии не менее 1,5 м;

-       минимальная ширина проходов с передней стороны пультов и панелей управления оборудованием ПЭВМ и УВО при однорядном его расположении должна быть не менее 1 м, при двухрядном - не менее 1,2 м ;

-       расстояние между рабочими столами с видеомониторами должно быть не менее 2 м, а расстояние между боковыми поверхностями - не менее 1,2 м;

-       экран монитора ПЭВМ и УВО располагают на расстоянии 600-700 мм от пользователя, но не ближе 500 мм, с учетом размеров цифровых знаков и символов.

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

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

Во время работы оператору запрещается:

-    касаться одновременно экрана монитора и клавиатуры; прикасаться к задней панели системного блока при включенном питании;

-       переключать разъемы интерфейсных кабелей периферийных устройств, при включенном питании;

-       загромождать верхние панели устройств посторонними предметами;

-       производить отключение питания во время выполнения активной задачи;

-       производить частые переключения питания;

-       допускать попадание влаги на поверхность системного блока, монитора, рабочую поверхность клавиатуры, дисковода, принтера и других устройств;

-       производить самостоятельно вскрытие и ремонт оборудования.

Оператору запрещается приступать к работе при обнаружении любой неисправности оборудования до ее устранения.

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

Заключение


В данном дипломном проекте решены две задачи:

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

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

Были рассмотрены вопросы исследования работы предприятия с точки зрения его эффективности и уровня автоматизации.

На основании этих исходных данных была поставлена задача проектирования автоматизированной системы управления, которая объединила бы все потоки информации в работе теплиц в единое целое.

Комплекс приложений и сервер БД используют локальную компьютерную сеть. Скорость передачи данных в сети является первым показателем скорости функционирования системы. Использование сервера Windows 2008 Server Database Edition на высокопроизводительной платформе Intel Xeon, пользовательские рабочие места используют стандартные «офисные» ПК с операционной системой Windows 7.

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

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

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

Список использованных источников и литературы


1.     «Windows Server 2008. Для профессионалов». Вишневский Алексей Викторович[Текст] /. - СПб.: Питер, 2010. - 832 с.

2.      Гамильтон, Б. ADO.NET Сборник рецептов. Для профессионалов. [Текст] / Б. Гамильтон - СПб.: Питер, 2005 - 576 с.

.        Гарнаев, А.Ю. Самоучитель QT Framework. [Текст] / А.Ю. Гарнаев - СПб.: БХВ - Петербург, 2005. - 688 с.

.        Гарнаев, А.Ю. Самоучитель Visual Studio .NET 2003. А.Ю. Гарнаев - СПб[Текст] /.: БХВ - Петербург, 2003.- 688 с.

.        Дейтел, Х. М. Как программировать для Internet и WWW. Х. М. Дейтел, П. Дж. Дейтел, Т. Р. Нието. Пер. с англ. [Текст] / - М.: ЗАО «Издательство БИНОМ», 2006 г. - 1184 с.

.        Макгрей, Э. «Система безопасности Windows». [Текст] / Э. Макгрей. - СПб.: Питер, 2005. - 796 с.

.        Малкин, С. Microsoft .NET Remoting[Текст] / C. Малкин, Д. Нафтел : Microsoft Press Русская редакция Microsoft, 2005. - 384 с.

.        Малкин, С. Microsoft .NET Remoting[Текст] / C. Малкин, Д. Нафтел : Microsoft Press Русская редакция Microsoft, 2005. - 384 с.

.        Прог раммирование для всех [Электронный ресурс] : Реализация баз даных на Microsoft SQL Server 2005 Режим доступа : http://www.realcoding.net.

.        Сборник технической документации [Электронный ресурс] : Реализация блочного шифрования в .NET : http://www.msdn.microsoft.com.

.        «Специалисты NIIT». Использование C#. Специальное издание Специалисты NIIT [Текст] /.- М.: Издательский дом «Вильямс», 2004 г. - 528

.        «Специалисты NIIT». Использование C++. Специальное издание Специалисты NIIT.- М.: Издательский дом «Вильямс», 2006 г. - 628 с.

.        Троелсен А. Программирвоание на языке С# 2008 [Текст] / А. Троелсен - : APRESS, 2008. - 1400 с.

.        Троелсен, Э. «C# и платформа .NET. Библиотека программиста». Э. Троелсен[Текст] /. - СПб.: Питер, 2005. - 796 с.

.        Фаронов В.В. Система программирования Widows. [Текст] / В.В. Фаронов. - СПб.: БХВ-Петербург, 2005. - 1021 с.: ил.

.        Фаронов В.В. Система программирования С++ Builder [Текст] /. - СПб.: БХВ-Петербург, 2003. - 912 с.: ил.

.        Феррара, Ф. Программирование web-сервисов для .NET. Библиотека программиста. Ф. Феррара, Мак-Дональд М[Текст] /. - Киев: BHV; СПб.: Питер, 2005. - 430 с.

.        Филимонов, А.Ю. Построение мультисервисных сетей Ethernet [Текст] / Филимонов А.Ю. - СПб. : BHV, 2007 г - 451c.

.        Финогенов, К.Г. WIN32 Основы программирования[Текст] / К.Г. Финогенов. - М.: Диалог - МИФИ, 2006. - 416 с.

.        Финогенов, К.Г. WIN32 Основы программирования[Текст] / К.Г. Финогенов М.: Диалог - МИФИ, 2006. - 416 с.

.        Шлее М. Qt4. Профессиональное программирование [Текст] / М. Шлее.- СПб.: БХВ-Петербург, 2007. - 880 с.

.        Шлендер, П.Э. Безопасность жизнедеятельности [Текст]: учебник / Шлендер П.Э., Маслова, С.И. Подгаецкий В.М. - М.: Вузовский учебник, 2008 г. - 173c.

.        Электронный журнал RSDN [Электронный ресурс] : Классы доступа к базам данных и безопастность Режим доступа : http://www.rsdn.ru.

24.    Язык программирования SQL [Электронный ресурс] : Синтаксис языка SQL Режим доступа : <http://www.sql.ru>.

Приложение А


Листинг аппаратной прошивки


//Номера в последовательности коммандного массива

#define DEVICE_CODE                         0x00

#define COMMAND_CODE      0x01

//Управление устройства по ИК каналу

#define IR_CONTROLED                      0x01

#define IR_PROTO_NEC                       0x01

#define IR_PROTO_SONY                    0x02

#define IR_PROTO_RC5                        0x03

#define IR_PROTO_RC6                        0x04

#define IR_PROTO_PANASONIC 0x05

#define IR_PROTO_JVC                        0x06

#define IR_PROTO_SAMSUNG            0x07

#define IR_PROTO_RAW                      0x08

//Датчик температуры Dallas

#define DS_TEMPERATURE_SENSOR_CODE                       0x03

#define DS_TEMPERATURE_GET_TEMPERATURE 0x01

#define TEMPERATURE_PRECISION 0x09

//Сенсор температуры и влажности

#define DHT_SENSOR_CODE              0x04

#define DHT_SENSOR_BASE_PIN      A0

#define DHT_SENSOR_ADRESS         0x02

#define DHT_GET_ALLDATA              0x01

#define DHT_GET_TEMPERATURE   0x02

#define DHT_GET_HUMIDITY            0x03

//Управление массивом реле через регистр

#define RELAY_CODE                          0x08

#define RELAY_INVERT_CODE          0x09

#define RELAY_ADRESS                      0x03 // Смещение определяющее адрес реле

#define RELAY_ON                               0x01

#define RELAY_OFF                             0x02

#define RELAY_STATUS                      0x03

#define RELAY_RESET                                     0x04

#define RELAY_PIN_DS                       0x28 //40

#define RELAY_PIN_SH                       0x29 //41

#define RELAY_PIN_ST                        0x2A //42

#define RELAY_INVERT_PIN_DS       0x2B //43

#define RELAY_INVERT_PIN_SH       0x2C //44

#define RELAY_INVERT_PIN_ST        0x2D //45

//Управление одним реле напрямую

#define PRIMARY_RELAY_CODE                               0x0A

#define PRIMARY_RELAY_INVERT_CODE  0x0B

#define PRIMARY_RELAY_PIN                                   0x2E//46

#define PRIMARY_RELAY_INVERT_PIN       0x2F//47

//Порт шины OneWire

#define ONE_WIRE_BUS          0x01

//Размер буфера данных

#define MAX_DATA_BUFFER 64

.ino

#include "DefinitionTable.h"

#include <dht.h>

#include <IRremote.h>

#include <OneWire.h>

#include <DallasTemperature.h>

#include <RegistryController.h>

//Определение типов данных

//Определение типа объединения для передачи ИК-комманд через интерфейс данных

union irCmd

{b[4];lval;

} ircmd;

//Определение типа объединения для передачи температуры через интерфейс данных

union dsTemp

{b[4];fval;

} dstemp;

//----------------------------------------------------------------

//Определение буфера для обмена с ПК

byte data[MAX_DATA_BUFFER];

byte dataLength;

//----------------------------------------------------------------

//Определение датчиков и переферии

DHT sensor = DHT();irSend;oneWire(ONE_WIRE_BUS);dstSensors(&oneWire);relay;relayInvert;

//----------------------------------------------------------------

setup()

{.begin(9600);=0;.init(RELAY_PIN_DS,RELAY_PIN_SH,RELAY_PIN_ST,false);.init(RELAY_INVERT_PIN_DS,RELAY_INVERT_PIN_SH,RELAY_INVERT_PIN_ST,true);(PRIMARY_RELAY_PIN, OUTPUT);(PRIMARY_RELAY_PIN, LOW);(PRIMARY_RELAY_INVERT_PIN, OUTPUT);(PRIMARY_RELAY_INVERT_PIN, HIGH);

}

loop()

{ln=0;(Serial.available()>0)

{=Serial.read();(ln>1)

{=ln;=0;(byte l=0;l<dataLength;l++)

{(Serial.available()<1);

[l]=Serial.read();

}();=0;

}

}

}

//Обработчик комманд поступивших с ПКprocessCommand()

{

(data[DEVICE_CODE]==DHT_SENSOR_CODE)

{();;

}(data[DEVICE_CODE]==IR_CONTROLED)

{();;

}(data[DEVICE_CODE]==DS_TEMPERATURE_SENSOR_CODE)

{();;

}(data[DEVICE_CODE]==RELAY_CODE)

{();;

}(data[DEVICE_CODE]==RELAY_INVERT_CODE)

{();;

}(data[DEVICE_CODE]==PRIMARY_RELAY_CODE)

{();;

}(data[DEVICE_CODE]==PRIMARY_RELAY_INVERT_CODE)

{();;

}

}

//Обработчик сенсора типа DHTXXprocessDHTSensor()

{.attach(DHT_SENSOR_BASE_PIN+data[DHT_SENSOR_ADRESS]);(500);t,h;.update();(sensor.getLastError())

{DHT_ERROR_OK:=sensor.getTemperatureInt();= sensor.getHumidityInt();;DHT_ERROR_START_FAILED_1:DHT_ERROR_START_FAILED_2:DHT_ERROR_READ_TIMEOUT:DHT_ERROR_CHECKSUM_FAILURE:(250);.update();=sensor.getTemperatureInt();= sensor.getHumidityInt();;

}(data[COMMAND_CODE]==DHT_GET_ALLDATA)

{.write(data[COMMAND_CODE]);.write(t);.write(h);

}

(data[COMMAND_CODE]==DHT_GET_TEMPERATURE)

{.write(data[COMMAND_CODE]);.write(t);

}(data[COMMAND_CODE]==DHT_GET_HUMIDITY)

{.write(data[COMMAND_CODE]);.write(h);

}

}

//Обработчик контроле ИК диапазонаprocessIRControl()

{(byte b=0;b<4;b++)

{.b[b]=data[b+3];

}(data[COMMAND_CODE+1]==IR_PROTO_NEC)

{.sendNEC(ircmd.lval, 32);

}(data[COMMAND_CODE+1]==IR_PROTO_SONY)

{.sendSony(ircmd.lval, 12);

}(data[COMMAND_CODE+1]==IR_PROTO_RC5)

{(dataLength==5)

{.b[2]=0;.b[3]=0;(byte z=0;z<3;z++)

{.sendRC5(ircmd.lval, 12);(50);

}

}

{long long cmd=0;(byte b=0;b<6;b++)

{<<=8;|=data[b+5];

}.sendRC5x( cmd, data[4],data[3]);

}

}(data[COMMAND_CODE+1]==IR_PROTO_RC6)

{.sendRC6(ircmd.lval, 20);

}(data[COMMAND_CODE+1]==IR_PROTO_PANASONIC)

{.sendPanasonic(ircmd.lval, 48);

}(data[COMMAND_CODE+1]==IR_PROTO_JVC)

{.sendJVC(ircmd.lval, 16,1);

}(data[COMMAND_CODE+1]==IR_PROTO_SAMSUNG)

{.sendSamsung(ircmd.lval, 32);

}(data[COMMAND_CODE+1]==IR_PROTO_RAW)

{

//irSend.sendRaw(ircmd.lval, 12);

}

}

//Обработчик сенсора температуры DallasprocessDSTemperature()

{(data[COMMAND_CODE]==DS_TEMPERATURE_GET_TEMPERATURE)

{thermAddr;(byte i=0;i<8;i++)

{[i]=data[i+2];

}.setResolution(thermAddr, TEMPERATURE_PRECISION);.fval=dstSensors.getTempC(thermAddr);.write(data[COMMAND_CODE]);(byte i=0;i<4;i++)

{.write(dstemp.b[i]);

}

}

}

//Обработчика управления реле через регистрprocessRelay()

{(data[COMMAND_CODE]==RELAY_ON)

{.on(data[RELAY_ADRESS]);

}(data[COMMAND_CODE]==RELAY_OFF)

{.off(data[RELAY_ADRESS]);

}(data[COMMAND_CODE]==RELAY_RESET)

{.reset();

}(data[COMMAND_CODE]==RELAY_STATUS)

{.write(relay.status(data[RELAY_ADRESS]));

}

}

//Обработчика управления инвертированного реле через регистр

void processInvertRelay()

{(data[COMMAND_CODE]==RELAY_ON)

{.on(data[RELAY_ADRESS]);

}(data[COMMAND_CODE]==RELAY_OFF)

{.off(data[RELAY_ADRESS]);

}(data[COMMAND_CODE]==RELAY_RESET)

{.reset();

}(data[COMMAND_CODE]==RELAY_STATUS)

{.write(relayInvert.status(data[RELAY_ADRESS]));

}

}

//Обработчика управления реле напрямуюprocessPrimaryRelay()

{(data[COMMAND_CODE]==RELAY_ON)

{(PRIMARY_RELAY_PIN, HIGH);

}(data[COMMAND_CODE]==RELAY_OFF)

{(PRIMARY_RELAY_PIN, LOW);

}

}

//Обработчика управления инвертированного реле напрямуюprocessPrimaryInvertRelay()

{(data[COMMAND_CODE]==RELAY_ON)

{(PRIMARY_RELAY_INVERT_PIN, LOW);

}(data[COMMAND_CODE]==RELAY_OFF)

{(PRIMARY_RELAY_INVERT_PIN, HIGH);

}

}

Реферат

Объект исследования - предприятие сельского хозяйства ООО «Экопродукт» Краснодарский край, ст. Новотиторовская.

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

Методы исследования - методы обобщения и анализа, теории систем, математические и логико-комбинаторные методы, имитационное моделирование.

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

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

Похожие работы на - Разработка автоматизированной системы управления технологическим процессом

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!