Автор работы: Пользователь скрыл имя, 10 Декабря 2012 в 16:36, дипломная работа
Дипломная работа посвящена описанию опыта создания распределенной информационно-управляющей системы ПоТок-С для филиала ПТС ОАО “Северо-Западный Телеком”, которая в настоящее время сдана в опытную эксплуатацию. Следует сказать, что ОАО “Северо-Западный Телеком” была одной из первых организаций в России, в которой в 1996 году начались работы по использованию систем для мониторинга режимов теплоснабжения и коммерческого учета потребления тепла сооружениями этой организации. Сложившаяся инфраструктура позволила в рамках выполнения этого проекта провести ряд исследований и демонстрационных экспериментов, результаты которых представляют интерес для системных интеграторов подобного рода проектов, а также для целого ряда смежных областей.
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ…………………………………………………………………3
ВВЕДЕНИЕ……………………………………………………………………………………….……4
1 ОБЗОР НАУЧНО-ТЕХНИЧЕСКОЙ ЛИТЕРАТУРЫ И ПАТЕНТОВ…………….…….…….6
1.1 Обзор систем мониторинга и управления распределенными объектами ……….…....6
1.2 Обзор контроллеров и встраиваемых компьютеров ……………………………………..21
2 ПОСТАНОВКА ЗАДАЧИ…………………………………………………………………………40
2.1 Описание проблематики……………………………………………………………………40
2.2 Общие требования к системам класса ИУС (СДМУ)…………………………………….41
2.3 Особенности построения и концепция РИУС ПоТок-С………………………………….43
2.4 Требования к программному обеспечению системы……………………………………..46
3 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ…………………………………….……..48
3.1 Низкоуровневое ПО контроллера ASK-Lab……………………….……………………...48
3.2 Высокоуровневое ПО системы видеоконтроля……………….………………………….68
4 ОЦЕНКА РЕЗУЛЬТАТОВ РАЗРАБОТКИ…………………………………………….…….......76
4.1 Оценка результатов разработанной системы…………………………………………….76
4.2 Оценка результатов разработанного ПО контроллера ASK-Lab……………………….78
4.3 Результаты применения системы видеоконтроля ……………………………….………80
ЗАКЛЮЧЕНИЕ…………………………………………………………………………………...….83
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ………………….……………………………..85
Ввиду указанных выше причин можно констатировать, что разрабатываемый программный продукт найдет наибольший спрос при работе под управлением операционных систем Windows 98, XP, и его разработка в данном случае займет наименьшее количество таких ресурсов, как время, затраты на программное обеспечение и оплату времени разработчика.
3.2.1.3 Выбор среды программирования
Критерии выбора среды программирования:
Перечисленным критериям
удовлетворяют среды
По каждой из этих сред накоплен большой опыт разработок. Перечисленные продукты компании Borland являются представителями RAD-сред (Rapid Application Development – быстрая разработка приложений), которые обладают широкими средствами быстрого создания интерфейса пользователя. Безусловно, используя среду разработки «Microsoft Visual C++» возможно создать более богатый интерфейс, чем позволяют продукты компании Borland, но использование данной среды для разработки интерфейса зачастую требует дополнительных временных затрат на поиск решения. Соответственно, разумным решением является использование для разработки одного из продуктов компании Borland.
В виду того что, для разработки программного обеспечения выбрана операционная система Windows, следует учесть, что большинство документации по системным функциям и функциям Windows API (Application Programming Interface – прикладной программный интерфейс) приведены на языке C. Не исключается использование данных функций и в других языках, но это может вызывать дополнительные неудобства при проектировании. К тому же при разработке планируется использование библиотек Microsoft DirectX®, работа с которыми наиболее удобна с использованием языков C/C++. Соответственно в качестве языка программирования для разработки целесообразно использование языка C++ и продукта компании Borland – «C++ Builder».
В настоящее время последняя версия для разработки 32-х разрядных Windows приложений - шестая версия среды C++ Builder. Однако для разработки необходимого нам программного обеспечения достаточно функциональных возможностей пятой версии. Таким образом, представляется целесообразным выбор в качестве среды программирования «Borland C++ Builder 5» (далее CBuilder).
3.2.2 Разработка структуры высокоуровнего ПО
Высокоуровневое ПО системы видеоконтроля за объектами управления предназначено для работы совместно с модулем IP-видеокамеры. Структура системы видеоконтроля приведена на рисунке 3.4.
Следует отметить, что модуль IP-видеокамера (вместе с видеокамерами и микрофоном) устанавливается непосредственно на объекте, за которым необходимо установить видео наблюдение. Разрабатываемое высокоуровневое ПО должно быть установлено на ПК в диспетчерском пункте (на АРМ инженера или оперетора).
Требования к функциям высокоуровнего ПО были приведены в пункте 2.4.2. ПО системы видеоконтроля может работать в трех режимах:
Режим оператора – это основной режим работы приложения. В данном режиме осуществляется:
Управление всеми функциями приложения в режиме оператора может осуществляться с помощью клавиатуры и «мыши».
Режим инженера служит для настройки приложения, настройка режимов работы IP-камеры. В данном режиме осуществляется:
Вход в режим инженера
осуществляется по нажатию специальной
кнопки на панели управления и возможен
только при выключенной
Режим администратора предназначен для просмотра журнала событий и настройки его параметров. ПО обеспечение может быть настроено таким образом, что в журнале событий будут фиксироваться все действия оператора и инженера (нажатие кнопок, запуск/останов видео и т.д.).
Внешний вид ПО системы видеоконтроля представлен на рисунке 3.5. ПО обеспечение системы видеоконтроля состоит из следующих панелей:
Среда программирования CBuilder предоставляет программисту широкие возможости по использованию готовых компонентов, классов и функций, так и созданию собственных. Использование компонентов позволяет быстро создавать приложения из готовых “кубиков”, добавляя в них требуемые функции.
Для разработки ПО системы видеоконтроля были использованы как стандартные, так и разработанные в СКБ специализированные компоненты. Список используемых компонентов:
TButton – стандартные компонент “кнопка”;
TComboBox – стандартные компонент “выпадающий список”;
TCheckBox – стандартные
компонент “флажок (
TEdit – стандартные компонент “текстовое поле”;
TLabel – стандартные компонент “надпись”;
TTimer – стандартные компонент “таймер”;
TUDPCamera – разработанный в СКБ компонент для работы с устройством IP-видеокамера (обмен данными);
TVideoDec – разработанный
в СКБ компонент для
TSoundPlay – разработанный в СКБ компонент для работы со звуком;
TMovieRec – разработанный в СКБ компонент для записи видео- и аудиофрагментов на жесткий диск (или носитель);
TLogWrite – разработанный в СКБ компонент для записи файла журнала событий;
TLogRead – разработанный в СКБ компонент для чтения файла журнала событий;
3.2.3 Методы отладки программного продукта
Среда программирования CBuilder предоставляет программисту мощные средства отладки, в том числе связанные некоторыми особенностями разработки кода под мультипрограммную ОС. В частности, CBuilder содержит интегрированный отладчик и Object Browser для контроля за результатом процесса компиляции двумя способами, а также ряд других сервисов нацеленных на поддержку процесса отладки. Использованные при разработке сервисы отладки перечислены и описаны ниже.
Отладка с помощью Integrated Debugger. Каждый раз, когда программа запускается из среды CBuilder, она выполняется под управлением отладчика. Это происходит, пока включена опция Integrated Debugger в странице Preferences диалоговой панели Environment Options. Когда программа выполняется под управлением отладчика, щелкнув по кнопке Pause в линейке SpeedBar, можно остановить выполнение. После остановки программы можно выполнять ее шаг за шагом, щелкнув по кнопке Step Over.
Но поскольку приложения Windows управляются сообщениями, нельзя выполнять код приложения шаг за шагом от начала до конца, как это можно сделать с приложением DOS. Поэтому основной способ отладки приложения CBuilder или любого другого приложения Windows состоит в том, чтобы установить точки останова в определенных местах кода, который нужно исследовать.
Указание точек останова. Существует ряд способов для указания точек останова в CBuilder. Самый простой метод заключается в следующем: щелкнуть в окне редактора слева от кода (между текстом и рамкой окна). При этом появляется пиктограмма (красная точка) и данная строка отображается другим цветом.
Установка точки останова допустимо, если в данной строке выполняется какой-либо код. Это исключает, например, объявления переменных или процедур, а также участки, которые лишены кода из-за оптимизации компилятора. При указании точки останова на одной из таких строк компилятор помечает ее как недоступную и не анализирует ее во время выполнения.
При размещении множества точек останова можно использовать команду Breakpoints меню View, чтобы открыть окно Breakpoint List. Один из пунктов в верхней части окна Breakpoint List предполагает добавление условия в точке останова, так чтобы программа останавливалась только при выполнении данного условия. Подобная возможность оказывается чрезвычайно полезной в тех случаях когда, выполнение кода, отмеченного точкой останова, может происходить многократно, однако при отладке интересует только определенное состояние программы и ее данных в этот момент.
Кроме того, окно Breakpoint List позволяет управлять присутствующими точками останова (добавлять, удалять, разрешать, запрещать).
Проверка значений. Если программа остановлена в отладчике, можно проверить значение любого идентификатора, который доступен в этой точке программы. Для этого в CBuilder существуют три способа: использовать диалоговую панель Evaluate/Modify, добавить элемент в окно Watch List или подвести курсор мыши к соответствующему имени идентификатора в тексте и увидеть его содержимое в появляющейся строке.
Диалоговая панель Evaluate/Modify имеет два режима работы. Можно использовать ее для проверки значения данного идентификатора или выражения, а также для изменения значения переменной.
Если же необходимо изменять значение переменной много раз, использование этой диалоговой панели замедляет процесс. Можно также установить наблюдение за любой переменной, свойством или компонентом, используя группы команд Add Watch. Список наблюдаемых объектов и их значения после остановки можно просмотреть в окне Watch List.
В данном разделе будут рассмотрены следующие вопросы:
4.1 Оценка результатов разработанной системы
Выполняя оценку разработанной системы, рассматриваются аспекты использования как результатов разработки в дипломной работе (использование контроллера ASK-Lab и системы видеоконтроля), так и результатов работы других участников проекта (высокоуровневое ПО диспетчерского пункта и т.д.).
4.1.1 Основные технические характеристики
Количество распределенных объектов (узлов теплоучета)
- до 400
Радиус системы (удаленность объектов от ДПС)
- до 50 км.
Способ обмена данными
- телефонные линии общего пользования (использование стандартных модемов);
- прямое подключение через интерфейс RS-232 устройств (теплосчетчики, контроллеры) к ПК для тестирования.
Время опроса узлов
- полный цикл опроса всех узлов: не более 1 часа;
- загрузка архивов с теплосчетчиков: от 1 часа до 1 суток.
Аппаратура верхнего уровня системы (ДПС)
- сервер БД;
- ПК (АРМы) диспетчеров, объединенные в ЛВС;
- модемы с выходом в городскую телефонную сеть.
Аппаратура нижнего уровня системы (узел теплоучета)
- 10 типов теплосчетчиков;
- контроллер ASK-Lab;
- теплорегулятор ECL-300 COMFORT;
- модемы с выходом в городскую телефонную сеть;
- аппаратура системы видеоконтроля.
ПО верхнего уровня системы
- СУБД ORACLE;
- ПО системы видеоконтроля;
- ПО для опроса теплосчетчиков;
- ПО для опроса теплорегулятора и задания его настроек;
Функции мониторинга
- считывание текущих
и архивных данных
- считывание данных и настроек теплорегулятора;
- считывание данных
и настроек контроллера ASK-Lab
- видеоконтроль за состоянием объекта.
Функции управления
- управление силовыми
устройствами, подключенными к контролеру ASK
Информация о работе Распределенная информационно- управляющая система поток-С