Автоматизированная система управления автономным водоснабжением
Описание системы автономного водоснабжения административного здания морского терминала ЗАО "Каспийский Трубопроводный Консорциум". Разработка и программная реализация алгоритма управления системой. Анализ и нормирование вредных производственных факторов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 14.11.2010 |
| Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Возможности традиционных сетей не могут удовлетворить постоянно растущие потребности в большей производительности и высоких эксплуатационных характеристиках системы при обеспечении повторяющейся и предсказуемой связи между устройствами. Простое увеличение скорости передачи данных и повышение эффективность протокола уже недостаточны. Эффективность сети определяется основной технологией, с помощью которой сеть управляет связью между подсоединенными устройствами. Преимущества сети, основанной на модели производитель/потребитель:
· Возросшая эффективность: источник посылает данные один раз и многочисленные узлы могут одновременно получить данные. Данные идентифицируются своим содержимым.
· Точная синхронизация: большее количество устройств может быть добавлено к сети без необходимости увеличения сетевого трафика и данные прибывают на все узлы в одно и то же время.
Обмен информацией по сети ControlNet. Самая важная функция ControlNet передавать критичную ко времени управляющую информацию (например, состояние ввода/вывода и блокировки управления). Одновременно передаётся и другая информация (например, не критичные ко времени сообщения, такие как загрузка и выгрузка программ), но она не смешивается с критичными ко времени сообщениями благодаря уникальному слоёному временному алгоритму ControlNet. По локальной сети ControlNet информация передаётся между двумя узлами путём установления логического соединения.
1.4 Разработка алгоритма управления системой
На этапе анализа был выявлен недостаток алгоритма управления системой водоснабжения, связанный с отсутствием возможности управления подсистемой ультрафиолетовой обработки воды. Рассмотрим существующий алгоритм автоматизированной системы управления автономным водоснабжением. Алгоритм реализован следующим образом: существует главная программа, из которой происходит вызов подпрограмм подсистем. Определим назначение данных подпрограмм.
В подпрограмме «P_MOTOR» реализована логика управления насосами водяных скважин. В этой программе реализован алгоритм «основной/запасной», обеспечивающий взаимозаменяемую работу насосов водяных скважин 40-PU-H004 и 40-PU-H005. Реализовано управление насосом водяных скважин 40-PU-H003 в ручном режиме. Помимо этого, программа реализует обработку аварийных сигналов реле низкого уровня, реле низкого и высокого давления, расходомеров, передавая их в подпрограмму «Alarms», а также, подсчитывает наработку насосов водяных скважин.
Подпрограмма «Alarms» обеспечивает обработку и вывод на SCADA - систему аварийных сигналов и сообщений блочной установки подготовки питьевой воды. К данным сигналам относятся аварийные сигналы клапанов, сигналы уровнемеров, расходомеров, датчиков давления. При наличии данных аварийных сигналов происходит подача общего аварийного сигнала системы.
Подпрограмма «Brine_System» реализует логику управления подсистемой подачи соли и подготовки рассола для обеспечения регенерации умягчителей, т.е. управляет клапанами данной подсистемы и обрабатывает аварийные сигналы реле низкого и высокого уровней в резервуаре хранения соли и в резервуаре подготовки рассола, передавая их в подпрограмму «Alarms».
Подпрограмма «Chlorine_System» отвечает за управление насосами подачи хлора 42-CIP-41, 42-CIP-42, 42-CIP-43, а также обрабатывает аварийные сигналы реле низкого и высокого уровней в резервуаре хранения хлора, передавая их в подпрограмму «Alarms».
Подпрограмма «Train_A» и подпрограмма «Train_B» реализуют алгоритм работы двух линий очистки воды, а именно: управление режимом работы линии, управление клапанами в автоматическом и ручном режимах, обработку аналоговых сигналов датчиков давления, расходомеров. Данные подпрограммы работают раздельно, что обеспечивает параллельную независимую работу линий очистки воды.
Подпрограмма «P_Regulator» обеспечивает управление бесступенчатых клапанов на входах резервуаров питьевой воды, реализует ПИД-регулятор, поддерживающий уровень в резервуарах питьевой воды на заданном уровне посредством управления клапанами, а также, обрабатывает аварийные сигналы реле низкого уровня резервуаров питьевой воды. Данные сигналы передаются в подпрограмму «Alarms».
Таким образом, можно отметить, что в указанном алгоритме отсутствует подпрограмма управления ультрафиолетовой дезинфекционной установкой. Существующий общий алгоритм управления системой водоснабжения представлен на рисунке 1.9.
Рисунок 1.9 - Существующий алгоритм управления системой водоснабжения
В соответствии с поставленной задачей необходимо обеспечить управление подсистемой управления ультрафиолетовой дезинфекционной установкой, т.е. обеспечить управление как в ручном, так и автоматическом режиме. На рисунке 1.10 представлен общий алгоритм управления системой водоснабжения, включающий подпрограмму управления ультрафиолетовой дезинфекционной установкой.
Рисунок 1.10 - Доработанный алгоритм управления системой водоснабжения
Рассмотрим алгоритм управления ультрафиолетовой дезинфекционной установкой. Данный алгоритм представлен на рисунке 1.11.
Рисунок 1.11 - Алгоритм управления ультрафиолетовой дезинфекционной установки
Данный алгоритм обеспечивает управление ультрафиолетовой дезинфекционной установкой в двух режимах: автоматическом и ручном. Оператор переводит установку в автоматический или ручной режим посредством разработанного программного интерфейса. При переводе оператором управления в автоматический режим, программируемый логический контроллер анализирует информацию с расходомера на выходе блочной установки подготовки воды FS7743 и, при наличии, потока воды, включает установку. При отсутствии выходного потока программируемый логический контроллер отключает установку. В случае неисправности расходомера, а также, по требованию оператора система управления может быть переведена в ручной режим. В данном режиме управление установкой обеспечивается посредством разработанного программного интерфейса автоматизированной системы управления автономным водоснабжением. Программная реализация алгоритма представлена в следующем пункте.
1.5 Программная реализация алгоритма системы водоснабжения
Разработав алгоритм управления ультрафиолетовой дезинфекционной установкой, необходимо реализовать его в программной среде и доработанный алгоритм загрузить в программируемый логический контроллер. Прежде чем перейти к программной реализации алгоритма подсистемы управления ультрафиолетовой дезинфекционной установкой, необходимо описать язык программирования, посредством которого реализуется данный алгоритм. При программировании промышленных логических контроллеров используется стандартный язык контактно-релейной логики или функциональных схем [1]. Разработанный алгоритм управления ультрафиолетовой дезинфекционной установкой реализован посредством релейной логики в программной среде RSLogix 17. Опишем состояние цепочки релейной логики для того, чтобы описать данный язык программирования. Контроллер анализирует инструкции релейной логики, исходя из состояния цепочки перед данной инструкцией (входного условия цепочки). На основе инструкции и входного условия цепочки контроллер устанавливает условие после инструкции (выходное условие цепочки), которое, в свою очередь, влияет на всякую последующую инструкцию. Если условие цепочки перед инструкцией - «истина», контроллер анализирует инструкцию и устанавливает выходное состояние цепочки на основе результатов ее выполнения. Если результатом инструкции является «истина», то выходное состояние цепочки - «истина», если же результатом инструкции является «ложь», то выходное состояние цепочки - «ложь». Также контроллер выполняет предварительное сканирование инструкций. Предварительное сканирование - это специальное сканирование всех процедур в контроллере. В процессе предварительного сканирования контроллер сканирует все главные процедуры и подпрограммы, но игнорирует переходы, при которых может быть пропущено выполнение инструкций. Контроллер выполняет все циклы и вызовы подпрограмм. Если какая-либо подпрограмма вызывается более одного раза, она выполняется при каждом вызове. Контроллер использует предварительное сканирование инструкций релейной логики для сброса не сохраняемого ввода/вывода и внутренних значений. При предварительном сканировании входные значения не являются текущими, а выходные данные не записываются. На рисунке 1.12 представлена структура релейной логики.
Рисунок 1.12 - Структура релейной логики
Перейдем к непосредственной программной реализации алгоритма управления подсистемой ультрафиолетовой дезинфекционной установки. На рисунке 1.13 представлена программная реализация алгоритма управления ультрафиолетовой дезинфекционной установкой.
Рисунок 1.13 - Программная реализация алгоритма управления ультрафиолетовой дезинфекционной установки
Рассмотрим инструкции и тэги, использованные при реализации данного алгоритма. В данном алгоритме использованы следующие инструкции:
· Инструкция XIC (Examine if Closed) - проверить на состояние «вкл».
· Инструкция XIO (Examine if Open) - проверить на состояние «откл».
· Инструкция OTL (Output Latch) - фиксация выхода.
· Инструкция OUT (Output Unlatch) - расфиксация выхода.
Рассмотрим данные инструкции подробнее. Инструкция программно подсвечена зеленым цветом в случае установки «истины». Инструкция XIC проверяет, установлен ли бит данных. Пример данной инструкции представлен на рисунке 1.14.
Рисунок 1.14 - Программная реализация инструкции XIC.
Если установлен нулевой бит тэга данных PV_UV_AUTO_MAN, то это разрешает следующую по порядку инструкцию (выходное условие цепочки - «истина»). Если входное условие цепочки - «ложь», то выходное условие цепочки устанавливается на «ложь». Алгоритм данной инструкции представлен на рисунке 1.15.
Рисунок 1.15 - Алгоритм инструкции XIC.
Инструкция XIO проверяет, сброшен ли бит данных. Пример данной инструкции представлен на рисунке 1.16.
Рисунок 1.16 - Программная реализация инструкции XIO.
Если сброшен нулевой бит тэга данных PV_UV_AUTO_MAN, то это разрешает следующую по порядку инструкцию (выходное условие цепочки - «истина»). Если входное условие цепочки - «ложь», то выходное условие цепочки устанавливается на «ложь». Алгоритм данной инструкции представлен на рисунке 1.17.
Рисунок 1.17 - Алгоритм инструкции XIO.
Инструкция OTL устанавливает (фиксирует) бит данных в логическую единицу - «истина». Пример данной инструкции представлен на рисунке 1.18.
Рисунок 1.18 - Программная реализация инструкции OTL.
Когда инструкция OTL разрешена, она устанавливает нулевой бит тэга данных UV_ON в логическую единицу. Данный бит тэга использован для управления ультрафиолетовой дезинфекционной установкой и отображения ее текущего состояния. Этот бит остается установленным пока он не будет сброшен, как правило с помощью инструкции OUT. Инструкция OTU сбрасывает бит данных (снимает фиксацию) в логический нуль - «ложь». Пример данной инструкции представлен на рисунке 1.19.
Рисунок 1.19 - Программная реализация инструкции OUT.
Обращаясь к рисунку 1.13 разберем на основании тэгов данных и инструкций программную реализацию алгоритма управления ультрафиолетовой дезинфекционной установкой. Нулевой бит тэга данных PV_UV_AUTO_MAN определяет режим работы ультрафиолетовой дезинфекционной установки. Данный бит устанавливается в логическую единицу при переходе в автоматический режим, и устанавливается в логический нуль при переходе в ручной режим. Инструкция XIC и инструкция XIO проверяют данный бит. Если данный бит установлен в логическую единицу, что представлено на рисунке 1.20, тогда выходное значения инструкции XIC устанавливается в логическую единицу и происходит переход к следующей инструкции XIC, которая проверяет наличие потока воды на выходном расходомере FS7743.
Рисунок 1.20 - Программная реализация алгоритма в автоматическом режиме работы установки и при наличии потока воды на выходном расходомере.
Данному расходомеру соответствует тэг данных A_41_FS7743. Поскольку в нашем примере данный бит также установлен, то выходное значение данной инструкции устанавливается в «истина», и инструкция OTL устанавливает нулевой бит тэга данных UV_ON, таким образом, запустив ультрафиолетовую дезинфекционную установку. При отсутствии потока на выходном расходомере FS7743 произойдет переход к нижней части цепочки и инструкция OTU сбросит нулевой бит тэга данных UV_ON, таким образом, остановив ультрафиолетовую дезинфекционную установку. Данная цепочка представлена на рисунке 1.21.
Рисунок 1.21 - Программная реализация алгоритма в автоматическом режиме работы установки и при отсутствии потока воды на выходном расходомере.
При переходе данной подсистемы в ручной режим происходит переход на цепочку, представленную на рисунке 1.22.
Рисунок 1.22 - Программная реализация алгоритма в ручном режиме запуска установки.
Если нулевой бит тэга данных PV_UV_AUTO_MAN установлен в логический нуль, что соответствует ручному режиму работы установки, и определяется инструкцией XIO, то инструкция XIC определяет значение нулевого бита тэга данных PV_UV_ON. Данный бит тэга установлен в логическую единицу при поступлении команды запуска данной установки с HMI. Для отключения установки используется цепочка, представленная на рисунке 1.23.
Рисунок 1.23 - Программная реализация алгоритма в ручном режиме отключения установки.
Если нулевой бит тэга данных PV_UV_AUTO_MAN установлен в логический нуль, что соответствует ручному режиму работы установки, и определяется инструкцией XIO, то инструкция XIC определяет значение нулевого бита тэга данных PV_UV_OFF. Данный бит тэга установлен в логическую единицу при поступлении команды отключения данной установки с HMI.
1.6 Разработка программного интерфейса для удаленного управления системой водоснабжения
В данном разделе представим описание существующего и разработанного программного интерфейса оператора для удаленного управления системой водоснабжения. В начале рассмотрим существующий интерфейс. Для локального управления системой автономного водоснабжения требуется присутствие оператора на объекте вне административного здания. Это создает большое неудобство в эксплуатации системы. Для визуализации технологического процесса используется дисплей с диагональю 8 дюймов. Визуализация выполнена на низком уровне, а интерфейс имеет недостатки, выявленные на этапе анализа. На рисунках 1.24 и 1.25 представлены примеры существующего операторского интерфейса.
Рисунок 1.24 - Главное окно существующего интерфейса
Рисунок 1.25 - Окно управления режимом работы линий очистки воды
Перейдем к рассмотрению разработанного в рамках дипломного проекта программного интерфейса. Программный интерфейс разработан с использованием прикладного программного обеспечения визуализации технологических процессов Wonderware InTouch 7.1 [2]. Насосы водяных скважин, блочная установка подготовки питьевой воды, а также исполнительные устройства и КИП резервуаров питьевой воды управляются выделенным ПЛК с дисплеем для операторского интерфейса. Данный дисплей используется для доступа ко всем зонам операторского интерфейса. Представим основные функции, которые предоставляет оператору разработанный программный интерфейс.
Работа оператора начинается с входа в меню авторизации, который обеспечивает работу оператора на двух языках: русском и английском. Программный интерфейс обеспечивает гибкое управление предоставлением прав доступа к разным типам оборудования. Данное окно позволяет изменять права доступа пользователей в пределах от 0000 (минимальные права) до 9999 (максимальные права), изменять пароли доступа, а также обеспечивает завершение работы пользователя. На рисунке 1.26 представлено окно, обеспечивающее авторизацию пользователя.
Рисунок 1.26 - Окно авторизации пользователя
При успешной авторизации пользователь переходит в основное окно, обеспечивающее визуализации системы водоснабжения. На рисунке 1.27 представлено главное окно программного интерфейса.
Рисунок 1.27 - Главное окно программного интерфейса
Данное окно обеспечивает возможность оператору следить за текущим состоянием системы в целом. Из данного окна предусмотрена возможность перехода в подсистемы управления водяными скважинами, блочной установкой подготовки воды, а также резервуарами питьевой воды. Переход осуществляется по наведению курсора на подсистему. В нижней части окна отображается текущие событие, с возможности просмотра всех событий посредством перехода в окно журнала событий. Журнал событий регистрирует аварийные события и обеспечивает хранение данных сроком 30 дней. К аварийным сигналов относятся аварийные сигналы клапанов, датчиков давления, реле низкого и высокого уровней, реле низкого и высокого давления, сбоев различных подсистем. Неподтвержденные аварийные сигналы отмечаются красным цветом. Возле каждого аварийного сигнала указываются дата и время. Для навигации в аварийных событиях используются клавиши со стрелками. Для стирания журнала используется клавиша стирания предыстории аварийных сигналов. Данное окно представлно на рисунке 1.28.
Рисунок 1.28 - Окно журнала событий
Программный интерфейс состоит из трех основных частей:
· Водяные скважины и промежуточная емкость.
· Система подготовки питьевой воды.
· Резервуары питьевой воды.
Рассмотрим данные подсистемы отдельно.
1.6.1 Водяные скважины и промежуточная емкость
На этом экране визуализируется текущее состояние данной подсистемы. На нем визуализируются насосы, которые находятся в работе, текущий расход, суммарный расход и время работы насосов. Оператор имеет возможность управлять отдельным насосом, клапаном на ходе промежуточной емкости. Интерфейс предоставляет оператору возможность отслеживания данных в виде графиков, вызывая меню графиков. На рисунке 1.29 представлено окно управления подсистемой водяных скважин и промежуточной емкости.
Рисунок 1.29 - Окно управления подсистемой водяных скважин и промежуточной емкости
1.6.2 Система подготовки питьевой воды
Данное окно обеспечивает возможность управления линиями очистки воды. На рисунке 1.30 представлено окно управления подсистемой блочной установки подготовки питьевой воды. На этом экране визуализируется текущее состояние всех систем в любой линии «A» и «В». На нем визуализируются все системы, которые находятся в работе, на обратной промывке, фильтрации стоков, направляемых в канализацию, рассола, медленной промывки, быстрой промывки.
Рисунок 1.30 - Окно управления подсистемой блочной установки подготовки питьевой воды.
1.6.3 Резервуары питьевой воды
Данное окно обеспечивает возможность управления бесступенчатыми клапанами на резервуарах питьевой воды, а также управление ПИД-регулятором, обеспечивающим поддержание определенного уровня в резервуарах. На рисунке 1.31 представлено окно управления подсистемой резервуаров питьевой воды.
Рисунок 1.31 - Окно управления подсистемой резервуаров питьевой воды.
1.6.4 Ультрафиолетовая дезинфекционная установка
Рассмотрим программную реализацию интерфейса управления ультрафиолетовой дезинфекционной установкой, представленную на рисунке 1.32.
Рисунок 1.32 - Окно управления ультрафиолетовой дезинфекционной установкой
Данное окно отображается по нажатию на ультрафиолетовую дезинфекционную установку из окна управления подсистемой блочной установки подготовки питьевой воды. Оператор имеет возможность выбирать режим работы данной установки, при этом, кнопки «Запустить» и «Остановить» доступны оператору только при переводе режима работы установки в автоматический. Окно отображает текущий режим и состояние системы.
1.6.5 Отчетная документация
Оператору, работающему с любым технологическим процессом, необходимо иметь возможность вести отчетную документацию по работе данного процесса. В соответствии с техническим заданием разработан интерфейс, обеспечивающий оператора данной возможностью. Отчеты хранятся в отдельной папке, что обеспечивает резервное хранение данных на длительный срок. В программе реализованы отчеты трех видов: суточный, недельный, месячный. Рассмотрим программную реализацию интерфейса меню отчетов, представленную на рисунке 1.33.
Рисунок 1.33 - Окно меню отчетов
Данное окно позволяет переходить в окно просмотра текущих отчетов, а также, открывать отчеты архива, хранящиеся в отдельной папке. Реализацию отчетов рассмотрим на примере ежедневного отчета, представленного на рисунке 1.34.
Рисунок 1.34 - Ежедневный отчет о состоянии автоматизированной системы автономного водоснабжения
1.6.6 Представление данных в виде графиков
Представление данных в виде графиков реального времени и графиков архива позволяют оператору отслеживать изменение состояния системы в удобном виде. Разработанный интерфейс позволяет оператору масштабировать графики для отслеживания текущего состояния системы по ряду параметров. К этим параметрам относятся данные датчиков давления и расходомеров. Интерфейс обеспечивает хранение графиков архива сроком 30 дней. На рисунке 1.35 представлено окно вызова графиков.
Рисунок 1.35 - Окно вызова графиков
Реализация графиков реального времени, отображающих данные, поступающие от датчиков давления, представлена на рисунке 1.36.
Рисунок 1.36 - Графики реального времени
На рисунке 1.37 представлено окно, отображающее графики датчиков давления в архиве. Интерфейс позволяет масштабировать график, с целью отслеживания данных в необходимый оператору момент времени.
Рисунок 1.37 - Графики архива
Разработанный интерфейс отвечает стандартам и требованиям компании ЗАО «Каспийский Трубопроводный Консорциум - Р». Помимо этого, интерфейс решает выявленные проблемы, т.е. обеспечивает: визуализацию технологических процессов на приемлемом уровне, ведение отчетной документации, резервное хранение данных, представление данных в виде графиков, гибкое управление предоставлением прав доступа к разным типам оборудования.
2 ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ
2.1 Описание технологии разработки программного обеспечения
2.1.1 Описание технологии разработки программной реализации алгоритма в среде RSLogix 5000
Рассмотрим технологию разработки программной реализации алгоритма. Алгоритм реализуется с использованием программного обеспечения RSLogix 5000 [1]. Данный программный продукт поддерживает архитектуру ControlLogix и представляет собой средство программирования контроллера Logix5550. В основе пакета RSLogix 5000 лежит простой в использовании редактор релейных схем RSLogix 500, создающий среду программирования, в которой используются возможности новой архитектуры. Отметим основные функциональные возможности данного программного продукта:
· Простое конфигурирование, обеспечиваемое графическим организатором контроллера, диалоговыми окнами конфигурации ввода/вывода, инструментом конфигурации движения, а также конфигурированием на основе технологии «укажи и щелкни».
· Развитая обработка данных с использованием как массивов, так и задаваемых пользователем структур в целях обеспечения необходимой для приложения гибкости, вместо того, чтобы подгонять его под конкретную структуру памяти, определяемую памятью таблицы данных контроллера.
· Простые в использовании методы адресации ввода/вывода.
· Редактор релейных схем свободного формата, позволяющий вносить изменения одновременно в несколько цепочек логики, а также вводить логику либо посредством интерфейса, использующего технологию «укажи и щелкни», либо по приглашению на ввод ASCII.
· Редактирование и навигация с помощью технологии «перенести и положить» с целью быстрого перемещения элементов данных из одного файла в другой, цепочек из одной процедуры или проекта в другою (другой), а также команд из одной цепочки в другую в пределах проекта.
· Организация логического приложения с использованием структур задач, программ и процедур.
· Возможность диагностического мониторинга, включая область индикации состояния, отражающую текущее состояние контроллера, возможность проверки программы и надежный монитор данных.
· Высоко интегрированная поддержка движения.
При открытии RSLogix 5000 будет представлен интерфейс, представленный на рисунке 2.1.
Рисунок 2.1 - Интерфейс среды реализации алгоритма RSLogix 5000.
Линейка меню предоставляет возможность выбора пунктов из меню, которые появляются, когда вы щелкаете мышью по какому-либо элементу этой линейки. Панель инструментов создания компонентов используется для создания новых компонентов проекта, например, тегов, процедур, программ. Панель режима отражает состояние программы и контроллера, т.е. указывает режим работы и наличие редакционных изменений. Панель инструментов для общей логики содержит все элементы релейной логической схемы, которые не являются командами (цепочки, ветви), а также наиболее часто используемые команды. Стандартная панель инструментов содержит множество функций (вырезать, копировать, вставить), которые используется неоднократно по мере разработки и тестирования логической программы. Панель инструментов редактирования релейных схем содержит все функции редактирования в режиме on-line, а также некоторые общие функции редактирования. Панель инструментов с закладками показывает мнемонические схемы команд по категориям, выполненным в виде закладок. Когда вы щелкаете мышью по закладке категории, панель инструментов команд, расположенная чуть выше, изменится в соответствии с данной категорией команд. Достаточно щелкнуть по команде, чтобы вставить ее в программу релейной логики. Строка состояния выводит текущую информацию о состоянии или приглашение пользователя. Организатор контроллера представляет собой графическое содержимое проекта по контроллеру. Область просмотра - это основное меню программного продукта RSLogix 5000, предоставляющее базовое средство просмотра различных редакторов. Окно результатов появляется в нижней части основного окна RSLogix 5000 после выполнения операций, приводящих к множеству результатов или ошибок. Это окно предоставляет информацию об ошибках и о состоянии выполняемой программы.
Технология разработки программного алгоритма на основе релейной логики рассмотрена в пункте 1.5.
2.1.2 Описание технологии разработки операторского интерфейса в среде Wonderware InTouch 7.1
Перейдем к рассмотрению технологии разработки операторского интерфейса. Интерфейс разработан с использованием программного обеспечения Wonderware InTouch 7.1. Широко известное в мире программное обеспечение человеко-машинного интерфейса InTouch HMI от компании Wonderware, предназначенное для визуализации и управления технологическими процессами, предоставляет удобные в использовании среду разработки и набор графических средств [3]. Приложения InTouch достаточно гибкие, чтобы удовлетворить как текущие, так и будущие потребности без необходимости в дополнительных инвестициях и усилиях. Доступ к универсальным приложениям InTouch обеспечивается с различных мобильных устройств, маломощных сетевых клиентов, компьютерных узлов и через Интернет. Кроме того, открытый и расширяемый интерфейс InTouch предлагает широкие возможности взаимодействия с множеством устройств промышленной автоматизации. На рисунке 2.2 представлен интерфейс среды разработки операторского интерфейса InTouch 7.1.
Рисунок 2.2 - Интерфейс среды разработки операторского интерфейса InTouch 7.1
Для построения и запуска приложений InTouch используется три компонента:
· Application Manager (менеджер приложений) для управления имеющимися приложениями,
· Window Maker для создания HMI приложений,
· Window Viewer для исполнения HMI приложений.
Application Manager включает в себя утилиты для управления InTouch приложениями. Используется для создания новых приложений или открытия существующих приложений в Window Maker или Window Viewer. Application Manger также используется для:
· Настройка свойства приложения InTouch, например имя или описание.
· Осуществление импорта и экспорта данных из/в базы данных тэгов приложения InTouch при помощи утилит DBDump и DBLoad.
· Конфигурация Window Viewer.
· Конфигурация разработки приложения по сети с одним сервером и несколькими клиентами.
После открытия Application Manager, в окне отобразится список приложения InTouch. В Application Manager отображаются приложения InTouch со следующей информацией: имя приложения, путь приложения, версия приложения, версия InTouch, описание приложения, разрешение экрана. Возможны три разных типа приложений InTouch:
· Обычные приложения InTouch.
· Приложения InTouchView.
· Приложения InTouchNAD.
· Приложения InTouch, управляемые из Application Server.
Обычные приложения InTouch - это стандартные приложения, созданные в Window Maker. При этом для сохранения используется внутренняя база данных тэгов и лицензия, основанная на количестве тэгов. Приложения InTouchView - это приложения InTouch, которые используют Application Server в качестве единственного источника данных. В любой момент можно переконвертировать обычное приложение InTouch в InTouchView и наоборот. Приложения InTouch для работы на автономных компьютерах или в распределенной сетевой структуре. Приложения InTouch Network Application Development (NAD) разрабатываются на сервере, а затем внесенные изменения распространяются на клиентские компьютеры. Когда приложения InTouch управляются из Application Server, то они создаются в Integrated Development Environment (IDE) как объекты InTouchApp. В IDE можно открыть редактор объектов InTouchApp, запустится Window Maker. По окончанию редактирования приложение можно сохранить и закрыть Window Maker. Объект InTouchApp будет зарегистрирован. Размещение объекта InTouchApp приводит запуску соответствующего InTouch приложения в Window Viewer.
Для разработки приложений используется среда Window Maker. Среда обеспечивает возможность использования инструментов объектно-ориентированной графики для создания анимированных окон и окон сенсорных дисплеев. Данные окна могут быть подключены к промышленным системам или другим приложениям Microsoft Windows. В Window Maker есть утилиты и инструменты для создания приложения InTouch:
· Базовые элементы - прямоугольники, окружности, линии и изображения, к которые можно привязать анимацию и реакцию на действие пользователя.
· Элементы управления, которые отображают данные или алармы.
· Окна - это панели, содержащие элементы интерфейса пользователя, при помощи которых оператор взаимодействует с производственными данными.
· Тэги - переменные, определенные в InTouch для хранения и управления производственными данными. Например, можно использовать тег для сохранения значения уровня в резервуаре, а также для анимационной связи.
· ActiveX компоненты - компоненты, которые импортируются в InTouch для выполнения определенных функций, например отображение текущих аварий.
· Анимационные связи - это свойства простых и сложных объектов, которые используются для анимации состояния производственного оборудования, или для передачи введенной пользователем информации.
· Мастера - предварительно созданные сложные объекты, которые выполняют определенные функции, например, слайдеры и измерительные приборы.
· База данных предварительно созданных промышленных символов и графических элементов.
· SymbolFactory - большая библиотека, символов связанных с промышленностью, которая позволяет быстро создать интерфейс пользователя промышленного оборудования.
· Скриптовый язык и набор встроенных функций для управления данными.
Окна InTouch - это панели, которые позволяют разработчику организовать интерфейс пользователя и сгруппировать связанные элементы. Например, можно создать одно окно, содержащее элементы отображения текущих производственных данных, а другое окно, содержащее элементы отображения архивных производственных данных. Существуют три типа окна:
· Замещающее - при открытии окна такого типа все остальные окна будут закрыты.
· Всплывающее - окно такого типа, обычно меньшего размера, и вызываются из главного окна, предназначены для временного отображения или ввода пользователем данных.
· Перекрывающее - при открытии окна данного типа все остальные окна остаются открытыми.
Сложные объекты можно создавать путем группирования базовых объектов для представления целостного объекта технологического процесса или просто для создания объектов, состоящих из более мелких частей. Например, можно создать сложный объект - вентиль, который представляет собой сочетание прямоугольника, линии и окружности. Сложный объект также включает в себя текст, который отображает состояние вентиля (открыт/закрыт). В InTouch существуют четыре различных типа сложных объектов определяемых пользователем. InTouch содержит предварительно созданные объекты, которые можно использовать для визуализации технологического процесса [4]. Мастера - это шаблонны объектов с определенными окнами конфигурирования. Мастера позволяют снизить время на разработку, потому как нет необходимости в рисовании и конфигурировании отдельных компонентов. Типичным мастером InTouch является - слайдер. Используется для установки аналогового значения. Для создания дополнительных мастеров требуется программный пакет Wonderware Extensibility Toolkit, и знание языка программирования С. ActiveX объекты обладают свойствами и методами и событиями, которые можно использовать в режиме исполнения, для управления объектом. В приложение InTouch можно импортировать ActiveX объекты сторонних производителей. Типичным ActiveX объектом, является AlarmViewer, который включен в InTouch. AlarmViewer отображает текущие алармы приложения. Symbol Factory - это библиотека объектов, которые можно использовать для представления элементов оборудования производственного процесса. Библиотека содержит объекты - трубы, двигатели, вентили, танки и насосы. Любой объект можно настроить набором анимационных связей и опций. В InTouch определяются теги, которые используются для хранения и управления производственными данными или для внутренних вычислений. Например, можно определить вещественный тег (Real), назвать его TankLevel, который содержит вещественное значение уровня в танке. Или, можно создать дискретный тег, который отображает состояние вентиля (0-закрыт/1-открыт). Теги имеют несколько общих свойств, которые сохраняются в полях тега, например имя тега, качество значения тега. При помощи скрипта или действием оператора осуществляется выбор назначения тега указателя на тег источник. Супертеги позволяют определить составные типы тегов. Теги, принадлежащие шаблону супертега соответствуют общим свойствам компонента производственного процесса. Супертеги позволяют сократить время разработки. Вместо создания набора тегов для каждого компонента производственного процесса, можно тиражировать шаблон Супертега и создавать отдельные экземпляры для каждого компонента, имеющего схожие свойства. Например, можно создать экземпляры супертегов для всех одинаковых насосов в группе резервуаров из одного шаблона супертега. В шаблоне супертега можно организовать до двух уровней вложенности тегов элементов. Шаблон супертега может содержать до 64 тегов элементов. А каждый элемент в свою очередь может содержать до 64 тегов подэлементов. В результате шаблон супертега может содержать до 4095 тегов. InTouch имеет систему алармов, которая поддерживает данную функциональность. Предупреждает оператора, когда значение производственного параметра отклоняется больше, чем на определенное количество процентов от желаемого значения. Аларм по скорости изменения (Rate of Change Alarm) - аларм возникает, когда значение изменяется быстрее, чем это допустимо. InTouch может также регистрировать также и события, которые являются сообщениями о кратковременных происшествиях в системе. В InTouch можно использовать скриптовый язык программирования и большую библиотеку встроенных функция для выполнения математических вычислений с тегами и для выполнения других задач. Скриптовый язык программирования InTouch основа на BASIC [5]. Часть кода написанного на языке программирования InTouch обычно называют скриптом. Скрипт может быть привязан, например, к нажатию кнопки, открытию окна или выделению объекта. Для построения более надежных приложений, Вы можете использовать скриптовый язык InTouch - QuickScript. Существует семь типов скриптов и множество встроенных скриптовых функций. Семь типов скриптов различаются причиной их выполнения. Например, скрипт приложения выполняется, когда приложение запускается, закрывается или работает. Скрипты по изменению данных выполняются, когда изменяется значение конкретного элемента. Скрипты окон выполняются, когда окно
открывается, закрывается или открыто. Встроенные скриптовые функции включают математические функции, тригонометрические функции, функции работы со строками и другие. Использование таких функций, позволяет сэкономить время при разработке проекта. Скрипты InTouch могут включать Object Linking и Embedding (OLE) объекты, а так же ActiveX объекты. Для создания более сложных конструкций в приложении, можно также использовать локальные переменные, условные операторы, циклы при создании скриптов. Все скрипты в InTouch HMI выполняются по срабатыванию какого-либо условия. Каждый тип скрипта имеет одно или несколько условий для запуска выполнения скрипта. В редакторе скриптов, можно выбрать тип условия срабатывания, по которому будет выполняться скрипт. При выборе условия, выбирается когда, и как будет выполняться скрипт. Вы можете сконфигурировать различные типы условий, основанные на действиях пользователя, внутренних состояниях, и изменениях значений тегов. Действия пользователей включают нажатия кнопок, нажатие на графические элементы. Условия по внутренним состояниям может включать в себя запуск Window Viewer. QuickScript - это библиотека встроенных функций, которые можно использовать в скриптах InTouch. Данные функции могут обрабатывать и возвращать значения в скрипты InTouch. При создании скрипта в InTouch ему назначается условие выполнения, которое при срабатывании приводит к выполнению скрипта. Данное условие определяет тип скрипта. Анимационные связи - это свойства объектов интерфейса пользователя в окнах InTouch. Можно установить поведение и появление объектов, путем конфигурирования их анимационных связей. Можно привязать к объекту теги таким образом, чтобы при изменении значения тега объект перемещался в горизонтальном или вертикальном направлении. Это может быть использовано для анимирования объектов, например, перемещающийся с уровнем в танке текст или в качестве движка слайдера. Можно также привязать объект к тегу таким образом, чтобы при изменении значения тега объект вращался вокруг своей оси или любой другой точки. Перемещение объектов можно использовать также для записи значения в тег. В InTouch существуют заранее созданные мастера, которые можно использовать в приложениях. В InTouch имеются ActiveX объекты, которые можно использовать в приложении. Некоторые из этих ActiveX объектов: AlarmViewer позволяет отобразить в табличном виде текущие алармы, сгенерированные InTouch или другим источником провайдером алармов. В ActiveX объекте AlarmViewer можно также осуществлять подтверждение алармов, AlarmTreeViewer позволяет просмотреть, выбрать текущие провайдеры алармов и группы алармов в древовидном меню, AlarmDBView позволяет отобразить в табличном виде архив алармов из базы данных.
Window Viewer - это среда исполнения InTouch. При запуске Window Viewer, приложение осуществляет подключение к данных и начинает обновление значений тегов и анимационных связей. Кроме широких возможностей приложения InTouch, работающего режиме исполнения, можно использовать независимую от приложения функциональность самого Window Viewer. Для запуска необходимо нажать на кнопку «RunTime» в верхней части окна среды Window Maker.
2.2 Разработка документации по работе с программным обеспечением
При запуске программы открывается окно авторизации, обеспечивающее гибкое управление предоставлением прав доступа к разным типам оборудования. Для работы необходимо ввести имя оператора, нажав на кнопку «Введите имя пользователя», что представлено на рисунке 2.3.
Рисунок 2.3 - Окно авторизации пользователя
Открывается окно ввода имени и пароля, представленное на рисунке 2.4.
Рисунок 2.4 - Интерфейс ввода имени
Введя имя пользователя, необходимо ввести пароль, воспользовавшись интерфейсом ввода пароля, аналогичным интерфейсу ввода имени. По окончании ввода имени и пароля, эти данные отображаются в строке в верхней части окна авторизации пользователей, представленном на рисунке 2.5.
Рисунок 2.5 - Окно авторизации пользователей
Для работы в системе, необходимо нажать на кнопку «Войти в систему», что представлено на рисунке 2.6.
Рисунок 2.6 - Окно авторизации пользователей
Пройдя авторизации, вы попадаете в главное окно интерфейса меню, представленное на рисунке 2.7.
Рисунок 2.7 - Главное окно программного интерфейса
В данном окне оператор имеет возможность просматривать состояние системы в целом. Для перехода в подсистемы системы автономного водоснабжения, необходимо нажать на соответствующую подсистему: насосы водяных скважин, блочная установка подготовки питьевой воды, резервуары питьевой воды. В окне подсистемы оператор имеет возможность управлять исполнительными устройствами. Для управления клапаном необходимо нажать на соответствующий клапан. По нажатию открывается всплывающее окно управления соответствующим исполнительным устройством, представленное на рисунке 2.8. Для открытия клапана нажмите на кнопку «Открыть», для закрытия клапана нажмите «Закрыть». В строке состояния нижней части окна отображается текущее состояние клапана и режим работы линии.
Рисунок 2.8 - Окно управления клапаном
Для управления насосом необходимо нажать на соответствующий насос. По нажатию открывается всплывающее окно управления соответствующим исполнительным устройством, представленное на рисунке 2.9.
Рисунок 2.9 - Окно управления насосом
Окно обеспечивает управление режимом работы насосом. Для перехода в автоматический режим нажмите на кнопку «Авто», для перехода в ручной режим нажмите на кнопку «Ручной». Текущий режим работы насоса отображается в строке состояния в верхней части окна. Для пуска насоса нажмите на кнопку «Запуск», для останова нажмите на кнопку «Стоп». Данные кнопки доступны только в ручном режиме работы насоса.
Для управления бесступенчатым клапаном необходимо нажать на соответствующий клапан. По нажатию открывается всплывающее окно управления соответствующим исполнительным устройством, представленное на рисунке 2.10.
Рисунок 2.10 - Окно управления бесступенчатым клапаном
Окно обеспечивает управление бесступенчатым клапаном. Режим работы клапана отображается в строке состояния в нижней части окна. Для управления клапаном выберете процент открытия клапана путем ввода данного значения под шкалой «CV».
Для управления ультрафиолетовой дезинфекционной установкой необходимо нажать на соответствующую установку. По нажатию открывается всплывающее окно управления соответствующим исполнительным устройством, представленное на рисунке 2.11.
Рисунок 2.11 - Окно управления ультрафиолетовой дезинфекционной установкой
Для перехода в автоматический режим нажмите на кнопку «Авто», для перехода в ручной режим нажмите на кнопку «Ручной». Текущий режим работы установки отображается в строке состояния в верхней части окна. Для пуска насоса нажмите на кнопку «Запустить», для останова нажмите на кнопку «Остановить». Данные кнопки доступны только в ручном режиме работы насоса.
Для просмотра аварийных сигналов необходимо нажать на строку аварийных сигналов в нижней части окна подсистем. Для просмотра отчетов и графиков нажмите на соответствующие кнопки «Меню отчетов» и «Меню графиков» в нижней части окна. Для навигации в системе автономного водоснабжения необходимо использовать кнопки «Предыдущее» и «Следующее». Для окончания работы нажмите на кнопку «Закончить работу» в окне авторизации пользователей, перейдя в него нажав на кнопку «Завершить работу» в главном окне программного интерфейса.
3 ТЕХНИКО-ЭКОНОМИЧЕСКИЙ РАЗДЕЛ
3.1 Расчет трудоемкости разработки программы
Себестоимость программного обеспечения зависит в первую очередь от трудоемкости разрабатываемой программы. Трудоемкость программы складывается из шести составляющих трудности разработки ПО, связанных с соответствующими операциями разработки ПО [6]:
1. Затраты труда на подготовку описания задачи
2. Затраты труда на исследование алгоритма решения задачи
3. Затраты труда на разработку блок-схемы алгоритма
4. Затраты труда на программирование по блок-схеме
5. Затраты труда на отладку программы
6. Затраты труда на подготовку документации
Общая трудоемкость:
Базовым показателем для определения затрат труда является условное число операторов в разрабатываемой программе:
,
где
- условное число операторов;
- число операторов в исходном коде программы;
- коэффициент сложности программы (1,25..2);
- коэффициент коррекции программы в ходе её разработки (0,05..0,1).
Для разрабатываемой программы = 5000 операторов, а исходя из особенностей разработки ПО, имеет смысл принять = 1,4 и = 0,08.
Тогда получим:
Трудоемкость выполнения операций зависит от квалификации программиста и учитывается коэффициентом квалификации к, определяемым по таблице 3.1:
Таблица 3.1 - Коэффициенты квалификации
|
Опыт работы |
Коэффициент квалификации |
|
|
До 2-х лет |
0,8 |
|
|
От 2-х до 3-х лет |
1 |
|
|
От 3-х до 5-и лет |
1,1..1,2 |
|
|
От 5-и до 7-и лет |
1,3..1,4 |
|
|
Более 7-и лет |
1,5..1,6 |
Для дальнейших расчетов примем исходя из опыта работы исполнителя в должности программиста от 2-х до 3-х лет.
Трудоемкость отдельных операций разработки ПО определяется следующим образом:
Описание задачи:
,
где
- минимальное;
- наиболее вероятное;
- максимальное время на подготовку описания задачи.
Примем: = 24 часа (3 рабочих дня), = 32 часов (4 рабочих дней) и = 48 часа(6 рабочих дней), Получим:
часа.
Исследование алгоритма решения задачи:
,
где
- коэффициент недостаточности описания задачи, в зависимости от сложности задачи принадлежит к диапазону (1,2..1,5).
Примем В=1,2 и получим:
часов.
Разработка блок-схемы алгоритма:
часов.
Программирование по блок-схеме:
часа.
Отладка программы:
часов.
Подготовка документации:
,
где
- затраты на подготовку рукописи:
часов.
- затраты на оформление документации:
часа.
Общие затраты на подготовку документации:
часа.
Суммарные затраты труда на разработку программы составляют:
=33+113+378+344+1890+662=3420 часов.
3.2 Расчет затрат на разработку программного обеспечения
Затраты на разработку программного обеспечения делятся на [6]:
1. Материалы и комплектующие;
2. Основная заработная плата;
3. Дополнительная заработная плата
4. Отчисления по социальному страхованию;
5. Эксплуатационные затраты:
5.1. Электроэнергия;
5.2. Техническое обслуживание и эксплуатационный ремонт;
5.3. Амортизация;
6. Накладные расходы.
Рассмотрим составляющие затрат по отдельности:
Затраты на материалы являются суммой затрат на материалы отдельных видов, которые определяются по формуле для каждого вида материалов:
,
где
- стоимость данного вида материалов;
- цена единицы материалов;
- количество единиц материалов и комплектующих, использованных в процессе разработке материалов.
Затраты на материалы для разработки ПО представлены в таблице 3.2.
Таблица 3.2 - Затраты на материалы для разработки ПО
|
Наименование материалов и ед. Измерения |
Цена ед., руб. |
Количество ед. |
Стоимость, руб. |
|
|
Диск DVD-RW 4.7 Гб, шт. |
40 |
2 |
80 |
|
|
Картридж для принтера HP чёрно-белый, шт. |
500 |
1 |
500 |
|
|
Бумага А4, пачка 500 листов |
130 |
1 |
130 |
|
|
Итого: |
-- |
-- |
710 |
Итого, общие затраты на материалы составляют 710 рублей.
Основная заработная плата:
,
Где
- тарифная ставка;
- общие трудозатраты;
- среднее число рабочих дней в месяце (24 дня).
Заработная плата для инженера-программиста будет исчисляться исходя из коэффициента 12 разряда тарифной ставки и составит 2404,8 рубля (= МРОТ*К = 1440*1,67). Тогда, затраты на основную заработную плату будут равны:
р.
Дополнительная заработная плата:
р.
Отчисления по единому социальному налогу:
р.
Эксплуатационные затраты:
,
где
- стоимость часа рабочего времени;
,
где
- годовая стоимость эксплуатации;
- эффективный фонд рабочего времени;
,
где
= 288 - номинальное число рабочих дней в году;
= 8 часов - продолжительность рабочего дня;
= 2% - планируемый процент времени на ремонт компьютера.
При данных значениях эффективный фонд составляет:
часов
Годовая стоимость эксплуатации:
,
где
- стоимость электроэнергии;
- затраты на техническое обслуживание и ремонт;
- амортизация.
Стоимость электроэнергии:
,
где
- потребляемая мощность, для современного ПК, применяемого для разработки ПО,
составляет 0,4 кВт,
= 0,8 - коэффициент загрузки,
= 1,7 р. - стоимость киловатт-часа электроэнергии.
При этом, затраты на электроэнергию составят:
р.
Затраты на техническое обслуживание и ремонт принимаются в размере 2,5% от стоимости компьютера ( = 25000 рублей, то есть рублей).
Затраты на амортизацию:
,
где
- норма амортизации:
,
где
= 5% Ск - 1250 рублей - стоимость ликвидации;
- нормативный срок службы компьютера.
С учетом быстрого морального устаревания ПК, особенно используемых для разработки ПО, то есть ПК, соответствующих последним технологическим достижениям, возьмем =3 года и получим величину затрат на амортизацию:
р.
Стоимость часа работы составит:
Эксплуатационные затраты составят:
р.
Накладные расходы:
р.
Себестоимость разрабатываемого программного обеспечения:
р
В таблице 3.3 сведены все статьи расхода на разработку программного обеспечения.
Таблица 3.3 - Сводная таблица затрат на разработку программного обеспечения
|
Вид затрат: |
Сумма, рублей: |
Процентное соотношение, % |
||
|
Материалы и комплектующие |
710 |
0,6 |
||
|
Основная заработная плата |
42835,5 |
38 |
||
|
Дополнительная заработная плата |
4283,55 |
3,8 |
||
|
Отчисления по социальному страхованию |
12250,95 |
10,9 |
||
|
Эксплуатационные затраты |
Затраты на электроэнергию |
1228,35 |
1,1 |
|
|
Амортизация |
7916,66 |
7,1 |
||
|
Затраты на ремонт и техническое обслуживание |
625 |
0,5 |
||
|
Накладные расходы |
42835,5 |
38 |
||
|
Итого: |
112685,51 |
100 |
В результате проведенных расчетов, себестоимость разработки программного обеспечения составляет 112685 рублей 51 копеек.
3.3 Расчет экономической эффективности программного средства
Для оценки экономической эффективности примем расчетный период равным 3 годам [6]. В данный момент выплаты по депозитным счетам составляют 6%, а дивиденды по акциям предприятий находятся на уровне 5-12%. Исходя из этого, примем норму дисконта равной 12%.
Инвестиции в изделие представляют собой только затраты на разработку, то есть J0=112685,51руб. Дальнейшие инвестиции не планируются, поэтому J1=J2=0.
Подобные документы
Изучение теории управления образовательными учреждениями и ВУЗами. Проектирование, реализация и внедрение автоматизированной информационной системы для автоматизации кафедры ВУЗа. Описание разработанной системы, расчет экономической эффективности проекта.
дипломная работа [4,5 M], добавлен 09.03.2010Разработка автоматизированной системы управления холодильной установкой, позволяющей сократить время технологического процесса и обеспечивающую комфортные условия для контроля его параметров. Составление алгоритма данного оптимизированного управления.
курсовая работа [8,5 M], добавлен 22.12.2010Использование информационных технологий для планирования размещения оптимальных точек водоснабжения, используя теорию графов. Функциональные возможности разрабатываемого приложения. Программная реализация основных модулей на основе алгоритма Флойда.
курсовая работа [818,3 K], добавлен 31.01.2012Описание структуры обучающего блока. Проектирование его алгоритма и лингвистического и информационного обеспечения. Организация его взаимодействия с базой данных. Разработка графического интерфейса. Программная реализация основных функций приложения.
дипломная работа [2,1 M], добавлен 20.12.2015Теоретическое исследование вопроса и практическое применение. Общие сведения о графах. Алгоритм Дейкстры. Особенности работы в среде. Программная реализация. Описание алгоритма и структуры программы. Описание программных средств. Текст программы.
курсовая работа [1,0 M], добавлен 27.11.2007Анализ современного состояния систем автоматизации управления данными; учет инфраструктуры информационной системы и требования к ресурсам организации. Разработка системы управления данными на базе SharePoint-сайта, программная реализация и внедрение.
диссертация [4,1 M], добавлен 10.11.2011Изучение возможностей системы YouTrack. Аналитический обзор ее аналогов и их функциональности. Анализ требований к системе управления проектами и надстройке. Визуализация данных. Проектирование интерфейса надстройки. Определение технологий реализации.
курсовая работа [2,3 M], добавлен 13.09.2017Обоснование решений по автоматизированному решению информационных задач. Реализация расширения схем данных. Используемые классификаторы и системы кодирования. Структурные единицы сообщений. Нормативно–справочная информация. Описание программных модулей.
курсовая работа [1,9 M], добавлен 11.06.2014Разработка программы учета занятости компьютеров в лаборатории. Анализ требований, метод решения. Разработка алгоритма в виде структурных схем. Программная реализация в среде Borland Delphi. Минимальные системные требования для ее корректной работы.
дипломная работа [6,3 M], добавлен 10.06.2013Анализ предметной области и разработка структуры информационой системы (ИС) "Кадры". Описание информационных процессов. Разработка структуры БД и структуры ИС. Разработка структуры базы данных и интерфейсов. Реализация и тестирование ИС "Кадры".
курсовая работа [1,2 M], добавлен 06.01.2008
