Второй режим подразумевает, что к ПК через специальный интерфейс подключен аппаратный эмулятор, в данном случае MPLAB ICE 2000. Этот режим позволяет практически полностью воспроизвести работу реального микропроцессора. Запуск программ с использованием аппаратного эмулятора позволяет проводить отладку и тестирование ПО при работе с любыми аппаратными ресурсами микропроцессора и подключенными периферийными устройствами.

Режимы запуска программы выбираются из меню Debugger->Select Tool

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

Запуск и останов программы. Запуск программы осуществляется из меню Debugger->Run. Останов выполнения программы осуществляется из меню Debugger->Pause. После останова программы, средствами среды программирования могут быть доступны для просмотра и изменения данные (переменные), содержимое встроенной памяти EEPROM, значение регистров и портов ввода-вывода, а также положение программного указателя. Программа может быть запущена вновь с того места, в котором произошел останов из меню Debugger->Run. Полный останов программы осуществляется из меню Debugger->Halt. В этом случае, при запуске, программа выполняется с начала.

Пошаговое выполнение программы. После остановки программы можно осуществить пошаговое ее выполнение. Возможно два варианта:

Пошаговое выполнение всех без исключения команд (Debugger->Step Into)

Пошаговое выполнение команд без “захода” в тело функций (Debugger->Step Over)

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

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

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

При размещении множества точек останова можно использовать пункт меню Debugger->Breakpoints, чтобы открыть окно Breakpoint List. Окно Breakpoint List позволяет управлять присутствующими точками останова (добавлять, удалять, разрешать, запрещать).

Программный указатель. При любом останове программы, в левой части окна редактирования появляется пиктограмма (зеленая стрелка). Она указывает на строку (команду), на которой остановилось выполнение программы. Это и есть программный указатель. Программный указатель можно выставить в любом месте программы, нажав правую кнопку мыши в нужной строке программы в окне редактора и выбрав в контекстном меню пункт Set PC at Cursor. Таким образом, после запуска программы, она будет выполнятся с места, в котором установлен программный указатель.

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

Hardware stack;

Watch;

Program memory;

File Registers;

EEPROM.

Hardware stack - позволяет просмотреть последовательность точек возврата после прерываний и вызова функций. Отображается номер точки и адрес возврата.

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

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

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

EEPROM - позволяет просмотреть и изменить значение ячеек памяти EEPROM.

Особенности отладки, связанные с использованием технологии мОСРВ

Использование технологии мОСРВ при разработке ПО контроллера приносит некоторые особенности процесса отладки конечного кода.

Выше было сказано, что для описания структуры ПО под мОСРВ А3 используется специализированный инструментарий Конструктор А3. В конечном счете, Конструктор А3 позволяет описать взаимодействие задач системы, сделать настройку параметров их выполнения и т.д. Код самих задач пишется отдельно (например, в текстовом редакторе или в среде MPLab), задачи собираются в библиотеку или отдельные модули. Проект из Конструктора А3 транслируется в среду MPLab, и уже там может быть окончательно отлажен и протестирован.

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

Определение укрупненной структуры ПО и необходимых задач;

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

Описание структуры взаимодействия задач в Конструкторе А3 и трансляция проекта в среду MPLab;

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

Детализация структуры ПО, разбиение задач на подзадачи;

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

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

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

Окончательная отладка ПО в среде MPLab. Возможное исправление кода задач;

Формирование (изменение) библиотеки функции и драйверов на основе задач отлаженного ПО.

Проверка работоспособности ПО на примере серийного изделия “контроллер ASK-Lab”

На некотором этапе создания ПО возникает необходимость производить его отладку и тестирование с использованием реальных устройств в условиях их эксплуатации. В нашем случае это контроллер ASL-Lab, который программируется разрабатываемым ПО при помощи программатора PRO MATE II. Тестирование контроллера проходит в два этапа:

Тестирование и отладка ПО на “столе”, т.е. в помещении, где ведется разработка ПО, с использованием специализированного стенда-макета;

Тестирование на объекте Заказчика в реальных условиях эксплуатации.

Для тестирования контроллера применялось специально разработанное сотрудником СКБ приложение “Тестирование”, установленное на ПК. Приложение “Тестирование” обеспечивает обмен данными между ПК и контроллером ASK-Lab, а также позволяет проверить обмен данными со всеми устройствами, подключенными к контроллеру, и д.р. функциональные возможности контроллера.

На первом этапе проводились следующие типы тестирования:

Функциональное тестирование;

Нагрузочное тестирование.

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

В рамках функционального тестирования выполнялись следующие проверки (многократные):

Обмен данными между ПК и контроллером (проверка линии связи);

Обмен данными между ПК и периферийными устройствами, подключенными к контроллеру - теплосчетчик и теплорегулятор ECL Comfort 300 (проверка линии связи и интерфейса I2C);

Ввод пароля на контроллере (проверка клавиатуры, дисплея и энергонезависимой памяти EEPROM);

Проверка правильности выполнения управляющих команд при разных паролях (проверка работоспособности портов ввода-вывода и алгоритмов шифрования и дешифрования);

Чтение и запись параметров контроллера (проверка памяти программ и энергонезависимой памяти EEPROM);

Проверка всех остальных функций, описанных в спецификации.

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

В рамках нагрузочного тестирования выполнялись следующие проверки (многократные):

Передача с ПК на контроллер беспорядочного набора пакетов (проверка устойчивости к переполнению входного буфера);

Передача с ПК на контроллер беспорядочного набора команд чтения (проверка времени отклика и устойчивой работы системы);

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

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

Многократный ввод пароля и запись параметров контроллера (проверка памяти программ и энергонезависимой памяти EEPROM).

После любого типа тестирования, ПО могло быть модифицировано, вследствие выявления каких-либо ошибок или неправильного функционирования.

На втором этапе проводилось длительное тестирование контроллера ASK-Lab на объектах ПТС в реальных условиях эксплуатации. Длительность тестирования составляла 1-7 суток.

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

3.2 Высокоуровневое ПО системы видеоконтроля

Обоснование выбора инструментальных средств для разработки ПО

Выбор необходимых аппаратных средств

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

Процессор: Intel Pentium 3

Тактовая частота: 1000 МГц

Объем оперативной памяти: 256 Мб

Объем дискового пространства HDD: 10 Гб

Видеокарта: 32 Мб

Звуковая карта: встроенная

Монитор: 15”

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

Выбор базовой операционной системы

Операционная система Windows в применении на персональных компьютерах является в настоящее время преобладающей перед прочими ОС для IBM PC совместимых компьютеров. Причем наибольшее распространение на территории России имеют следующие версии: Windows 98 и ставшая очень популярной в последнее время Windows XP. К тому же Windows XP является одной из самых удачных операционных систем компании Microsoft, так как она объединяет в себе две концепции, которые компания Microsoft развивала до выпуска Windows XP параллельно: интерфейс, удобный для пользователя и работа в сети. Разрабатываемое программно обеспечение будет совместимо с несколькими операционными системами, а именно Windows 98, Me, 2000, XP.

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

Выбор среды программирования

Критерии выбора среды программирования:

Базовая операционная система - Windows XP для IBM PC совместимых ПК.

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

Поддержка объектно-ориентированного программирования.

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

Перечисленным критериям удовлетворяют среды визуального программирования, такие, как «Microsoft Visual C++», «Borland C++ Builder» и «Borland Delphi».

По каждой из этих сред накоплен большой опыт разработок. Перечисленные продукты компании 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).

Разработка структуры высокоуровнего ПО

Высокоуровневое ПО системы видеоконтроля за объектами управления предназначено для работы совместно с модулем IP-видеокамеры. Структура системы видеоконтроля приведена на рисунке 3.4.

Следует отметить, что модуль IP-видеокамера (вместе с видеокамерами и микрофоном) устанавливается непосредственно на объекте, за которым необходимо установить видео наблюдение. Разрабатываемое высокоуровневое ПО должно быть установлено на ПК в диспетчерском пункте (на АРМ инженера или оперетора).

Требования к функциям высокоуровнего ПО были приведены в пункте 2.4.2. ПО системы видеоконтроля может работать в трех режимах:

режим оператора;

режим инженера;

режим администратора.

Режим оператора - это основной режим работы приложения. В данном режиме осуществляется:

трансляция видео- и аудио- потока с IP-видеокамеры, назначенной диспетчером, на ПК, с воспроизведением изображения и звука;

управление параметрами изображения и звука;

управление переключением источников видеосигнала;

запись аудио-видео потока на диск.

Управление всеми функциями приложения в режиме оператора может осуществляться с помощью клавиатуры и «мыши».

Режим инженера служит для настройки приложения, настройка режимов работы IP_камеры. В данном режиме осуществляется:

выбор и настройка канала наблюдения;

выбор источников видеосигнала для режима автоматического циклического переключения;

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

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

выбор размера отображения видео информации;

выбор горячих клавиш для переключения активности канала наблюдения.

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

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

Внешний вид ПО системы видеоконтроля представлен на рисунке 3.5. ПО обеспечение системы видеоконтроля состоит из следующих панелей:

Панель управления (панель оператора);

Панель инженера (появляется при входе в режим инженера);

Панель администратора (появляется при входе в режим администратора);



До 4-х панелей видеонаблюдения (зависит от настройки ПО).

Среда программирования CBuilder предоставляет программисту широкие возможости по использованию готовых компонентов, классов и функций, так и созданию собственных. Использование компонентов позволяет быстро создавать приложения из готовых “кубиков”, добавляя в них требуемые функции.

Для разработки ПО системы видеоконтроля были использованы как стандартные, так и разработанные в СКБ специализированные компоненты. Список используемых компонентов:

TButton - стандартные компонент “кнопка”;

TComboBox - стандартные компонент “выпадающий список”;

TCheckBox - стандартные компонент “флажок (переключатель)”;

TEdit - стандартные компонент “текстовое поле”;

TLabel - стандартные компонент “надпись”;

TTimer - стандартные компонент “таймер”;

TUDPCamera - разработанный в СКБ компонент для работы с устройством IP-видеокамера (обмен данными);

TVideoDec - разработанный в СКБ компонент для декомпрессии сжатого видеоизображения;

TSoundPlay - разработанный в СКБ компонент для работы со звуком;

TMovieRec - разработанный в СКБ компонент для записи видео- и аудиофрагментов на жесткий диск (или носитель);

TLogWrite - разработанный в СКБ компонент для записи файла журнала событий;

TLogRead - разработанный в СКБ компонент для чтения файла журнала событий;

Методы отладки программного продукта

Среда программирования 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. ОЦЕНКА РЕЗУЛЬТАТОВ РАЗРАБОТКИ

В данном разделе будут рассмотрены следующие вопросы:

Оценка результатов разработанной системы;

Оценка результатов разработанного ПО контроллера ASK-Lab;

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

4.1 Оценка результатов разработанной системы

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

Основные технические характеристики

Количество распределенных объектов (узлов теплоучета)

- до 400

Радиус системы (удаленность объектов от ДПС)

- до 50 км.

Способ обмена данными

- телефонные линии общего пользования (использование стандартных модемов);

- прямое подключение через интерфейс RS-232 устройств (теплосчетчики, контроллеры) к ПК для тестирования.

Время опроса узлов

- полный цикл опроса всех узлов: не более 1 часа;

- загрузка архивов с теплосчетчиков: от 1 часа до 1 суток.

Аппаратура верхнего уровня системы (ДПС)

- сервер БД;

- ПК (АРМы) диспетчеров, объединенные в ЛВС;

- модемы с выходом в городскую телефонную сеть.

Аппаратура нижнего уровня системы (узел теплоучета)

- 10 типов теплосчетчиков;

- контроллер ASK-Lab;

- теплорегулятор ECL-300 COMFORT;

- модемы с выходом в городскую телефонную сеть;

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

ПО верхнего уровня системы

- СУБД ORACLE;

- ПО системы видеоконтроля;

- ПО для опроса теплосчетчиков;

- ПО для опроса теплорегулятора и задания его настроек;

Функции мониторинга

- считывание текущих и архивных данных теплосчетчиков;

- считывание данных и настроек теплорегулятора;

- считывание данных и настроек контроллера ASK-Lab;

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

Функции управления

- управление силовыми устройствами, подключенными к контролеру ASK-Lab;

- задание режимов теплорегулирования (настройка параметров теплорегулятора).

Функции автоматизации

- контроль ПО верхнего уровня системы нештатных ситуаций в автоматическом режиме

Сравнение с существующими аналогами

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

Большой объем работ по адаптации системы к существующей архитектуре объектов (замена большинства аппаратной части оборудования)

Ограничение на количество распределенных объектов (многие системы позволяют обслуживать не более 100 объектов)

Высокая стоимость аппаратно-программных ресурсов;

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

Использование продукта

Данные продукт, прежде всего, предназначен для использования в филиале ПТС ОАО “Северо-Западный Телеком”. Однако многие компоненты системы являются универсальными, и система, в целом, может использоваться во многих областях жилищно-коммунального хозяйства. РИУС ПоТок-С может быть легко переконфигурирована для различной топологии объектов в системе; в качестве узлов может быть использовано любое оборудование, поддерживающее соединение по стандартным интерфейсам RS232 или CANBus.

4.2 Оценка результатов разработанного ПО контроллера ASK-Lab

Разработанное низкоуровневое ПО предназначено для конкретного типа контроллера (ASK-Lab). Выполняя оценку разработанного ПО контроллера, рассматриваются в основном функциональные возможности контроллера ASK-Lab, которые обеспечиваются использованием данного ПО в контроллере.

Основные технические характеристики

Основные технические характеристики ПО контроллера ASK-Lab:

Возможность обращения к 3-м устройствам по одной линии связи (контроллер ASK-Lab, теплосчетчик и теплорегулятор ECL Comfort 300);

Настройка параметров контроллера;

Энергонезависимое хранение параметров контроллера;

Обмен данными с ПК по линии связи (телефонная линия или прямое соединение контроллера и ПК);

Использование протокола ASK-bus 3.1 в качестве протокола сетевого и транспортного уровня для обмена данными с ПК;

Обеспечение режима “прозрачности” (поддержка работы программного обеспечения предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)

Защита данных. Использование алгоритма ГОСТ 28147-89 для кодирования-декодирования команд управления и особо важных данных;

Считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort 300;

Изменения параметров теплорегулятора ECL Comfort 300;

Управление силовыми устройствами (до 8-и);

Протоколирование событий;

Контроль времени выполнения задач.

Сравнение с существующими аналогами

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

В РИУС ПоТок-С требовалось устройство, обеспечивающее возможность работы с 3-мя устройствами по одной линии связи, работы со стандартными 56К модемами и выполняющее функции коммуникации, мониторинга, управления и защиты информации. Разработанное ПО позволило использовать контроллер ASK-Lab в качестве такого устройства. Использование продукции других производителей существенно увеличило бы стоимость устройства, поскольку для реализации требуемых функции потребовалось бы использование нескольких аппаратных модулей и дорогостоящих средств разработки ПО.

Использование продукта

Основным назначением разрабатываемого программного продукта (запрограммированного в контроллер ASK-Lab) является обеспечение возможности работы контроллера ASK-Lab в составе РИУС ПоТок-С в качестве основного узла объектов, оснащенных теплорегулирующим оборудованием (теплорегулятор ECL-300 Comfort, датчики и исполнительные механизмы), и выполнение им коммуникационных и управляющих функций.

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

Так, например, за время работы над проектом контроллер ASK-Lab был использован в качестве контроллера системы управления движением автономного робота (некое подобие 4-х колесной тележки), а также основного звена в контуре управления тепловым режимом здания.

4.3 Результаты применения системы видеоконтроля

В рамках первого этапа реализации проекта в первом полугодии 2005 г. проводились инженерные эксперименты для проверки ряда новых подходов по обеспечению надежности управляющей подсистемы ПТС-2 в режимах ручного управления исполнительными механизмами с ДПС (с АРМ инженера). Для экспериментов была применена система видео контроля (высокоуровневое ПО для этой системы разработано в рамках дипломной работы), которая находился в одном здании с центральным ДПС. Структурная схема эксперимента представлена на рисунке 4.2.

Оператор подсистемы ПТС-2 с АРМ инженера может контролировать положение вентилей с помощью четырех камер, и таким образом у него появляется возможность контролировать результат собственных действий. Для передачи данных использовался 4-х канальный IP-видео контроллер с вейвлетовским сжатием.

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

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

Контроллер ASK-Lab обеспечивает возможность дистантного управления 8 каналами дискретного выхода (подключены силовые устройства). Для визуализации используется видеоизображение текущего состояния исполнительных механизмов.

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

К настоящему времени проведен ряд эксперименты как по визуальному контролю за текущими положением задвижек, так и по визуальному способу съема показаний с манометров. При этом сжатый видеопоток передавался по 100 Мбитной локальной сети на АРМ инженера, так как эксперимент проводился в теплопункте здания, в котором размещается диспетчерский пункт филиала ПТС ОАО “Северо-Западный Телеком”. При отображении информации с одной контрольной точки оператору представлялась возможность отслеживать ситуацию на объекте в телевизионном режиме, т.е. 25 кадров в секунду.

Следует отметить, что использованный модуль “IP-Видеокамера” использует мультиплицированный видеовход и при необходимости отображения двух и более точек возникают задержки, обусловленные тем, что минимальное время переключения между каналами составляет 250-300 мсек, что соответствующим образом ограничивает качество видео. Таким образом, при передаче команд управления по одному из каналов оказалось целесообразным отслеживать ее выполнение с помощью закрепленной за этим каналом камеры. При необходимости отслеживать ситуацию в 2-х и более контрольных точках разработанное ПО обеспечивало две возможности.

Во-первых, можно сканировать каналы по очереди с задаваемым оператором периодом переключения каналов, а во-вторых, использовать режим программного квадратора. В этом режиме на виртуальной панели экране отображается от двух до четырех видеопотоков с отображением времени получения последнего кадра с объекта. При расширении этого способа контроля на все объекты архитектура системы несколько усложниться. В этом случае потребуется обеспечить возможность подключения IP-контроллера к сети Интернет, что в условиях ОАО “Северо-Западный Телеком” не составляет проблемы, так как объекты ПТС сами образуют коммуникационную среду мегаполиса.

Был также выполнен ряд поддерживающих экспериментов по использованию модемов для передачи видеоизображений по коммутируемым линиям общего пользования. Как показали проведенные эксперименты, в этом случае в условиях г. Санкт-Петербурга имеется возможность передавать видеоизображение со скоростью 0.5-1 кадр/сек, что обеспечивает возможность контроля по видеоканалу в реальном времени.

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

В настоящее время этот компонент системы передан в опытную эксплуатацию в филиал ПТС ОАО “Северо-Западный Телеком”.

ЗАКЛЮЧЕНИЕ

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

В настоящее время существуют разные подходы к выбору аппаратного и программного обеспечения нижнего уровня для систем промышленной автоматизации, диспетчерского мониторинга и контроля. Есть примеры использования как готовых ПЛК [5], так и разработки собственных контроллеров [4], [6], [7]. Разработка уникальных контроллеров и программного обеспечения для них обеспечивает требуемую гибкость проекта, что является необходимым условием при реализации пилотных проектов и обеспечивает возможность эффективной поддержки системы за счет унификации ряда решений в коммуникационной составляющей систем.

Верификация разработанного ПО и работоспособности всей системы осуществлялась на протяжении отопительного сезона 2004-2005 посредством параллельной работы с комплексами Аструм и Кливер. При этом представляется важным подчеркнуть, что полученные с этих комплексов учетные данные использовались в качестве эталонных, что позволило существенно сократить время отладки и, соответственно, снизить стоимость разработки ПО. Разработанное ПО (низкоуровневое ПО контроллера ASK-Lab и высокоуровневое ПО системы видеоконтроля), рассматриваемое в рамках всего проекта в целом, позволило выполнить ряд особо важных функций по переводу существующей РИС ПТС-1 в разряд РИУС (ПоТок-С). Предложенные решения имеют универсальный характер и легко масштабируются для аналогичных применений в предприятиях жилищно-коммунального хозяйства, крупных компаниях с сетевой структурой. РИУС ПоТок-С отвечает всем требованиям к системам дистанционного мониторинга и управления [5], и имеет ряд интересных решений, таких как использование системы видеоконтроля на объектах (контроль действий оператора при выполнении им функций управления, визуальный мониторинг состояния объекта), применение алгоритмов шифрации при обмене конфиденциальной информацией и д.р.

В настоящее время РИУС ПоТок-С передан в опытно-промышленную эксплуатацию в диспетчерский центр АУЭ филиала ПТC ОАО “Северо-Западный Телеком”. При этом к системе подключено около сотни станций, из которых 10 оснащены автономными узлами регулирования, оборудованных контроллерами ASK-Lab. Одна станция оборудована системой видеоконтроля. На 2006 год запланировано подключение к этой подсистеме еще 14 узлов с автономным регулированием, и последующей установкой на всех таких узлах системы видеоконтроля.

Результаты работы были представлены на первый европейский конкурс студенческих работ ESPC-2005, проводимый под эгидой ISA (21.05.2005, Корк, Ирландия) и удостоены Золотой медали. Демонстрационный показ работы РИУС ПоТок-С представителям ГК ОАО “Ленэнерго” получил положительный отзыв. 12.12.2005 был подписан акт внедрения системы ПоТок-С. В настоящее время по результатам выполненной работы готовится серия публикаций с целью популяризации полученного при разработке опыта.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Анисимов А.Л., Астапкович А.М., Дмитриев С.В. и др. Проблемы и перспективы создания интегрированных коммунальных систем учета потребления энергоресурсов. // Cборник Информационно-управляющие системы и сети. Структуры. Моделирование. Алгоритмы. Политехника, СПб., 1999, с. 165-185.

Шумилов И.А., Анисимов А.Л., Астапкович А.М. и др. Перспективы создания интегрированных коммунальных систем учета потребления энергоресурсов. // Труды конференции Коммерческий учет энергоносителей 10-я конференция. Совершенствование измерений расхода жидкости газа и пара, Политехника, СПб., 1999, с. 340-360.

Ладугин Д.В. Интегрированная система коммерческого учета тепловой энергии и природного газа на базе программно-технических комплексов серии “КРУГ-2000”// Журнал Датчики и системы № 5, 2005, c. 2-5

Бартенев В.Г., Бартенев М.В Энергосберегающая модульная АСУТП для распределенных объектов “СИНТАЛ ТЕЛЕТЕРМ” // Журнал Датчики и системы, № 2, 2005, c. 32-35

Плющаев В., Грошева Л., Мерзляков В., Перевезенцев С., Зуев А., Пахомов А. Система дистанционного мониторинга и управления объектами. // Журнал Системы Технологической Автоматизации, № 2, 2003, с. 6-15.

Карташев А.А., Мартынов В.И. Организация учета энергоносителей на источниках теплоты в бюджетной и жилищно-коммунальной сфере г.Сургута // Труды конференции “Коммерческий учет энергоносителей” XX1-я международная научно-практическая конференция Санкт-Петербург, май, 2005, с. 321-324.

Титович Ю.В., Барашков В.М., Астапкович А.М., Касаткин А.А. Обслуживание индивидуальных тепловых пунктов в филиале “Петербургская Телефонная Сеть” ОАО “Северо-Западный Телеком”// Журнал “Энергосбережение”, № 4, 2005, с. 2- 6 .

Астапкович А.М. Микрооперационные системы реального времени // Монография, СПб: Политехника, 2002.

Астапкович А.М. (2003) Формализм адресно-временных карт для описания алгоритмов функционирования многоканальных систем управления. Введение в формализм адресно-временных карт. // Журнал Информационно-управляющие системы, № 4, 2003, с. 6-14.

Астапкович А.М. (2004) Формализм адресно-временных карт для описания алгоритмов функционирования многоканальных систем управления. Базовые объекты и операции с АТ-картами. // Журнал Информационно-управляющие системы, 2004, № 2, с. 26-37.

Астапкович А.М., Востриков А.А., Касаткин А.А, Чудиновский Ю.Г., Bishop R. Опыт использования информационно-управляющих сетевых систем для передачи видеоизображений. // Сборник Семинары ASK Lab 2001, с. 180-197.

Анисимов А.Л., Астапкович А.М., Востриков А.А., Елисеенко А.Г. , Кравченко Д.А., Плигин М.В., Сергеев М.Б., Суханов И.О. Система предоплаты за потребляемую энергию Кредо-Смарт 500 //Сборник: Микропроцессорные информационно-управляющие системы реального времени / Под общ. ред. М.Б.Сергеева. - СПб: Политехника, 2000, с.198 - 215.

ГригорьевМ.В., Шафер Е.С., Балихин И.Н., Плюшаев В.И. Аппаратно-программный комплекс для канализационных насосных станций // Журнал Водоснабжение и санитарная техника, №6, 2000.

Галузов М. В. Комплексная диспетчеризация объектов различного назначения // материалы сайта www.rtservice.ru, Информационные системы учета энергоресурсов.

Материалы сайта www.logika.spb.ru.

ThinkIO - универсальное решение для промышленной автоматизации // RTSoft Средства и системы автоматизации, Каталог продукции, 2005.

Роботы для слежения за электрической сетью // материалы сайта www.English.Eastday.com.

Соловьев С.А. Контроллеры SCADAPack в системах коммерческого учета энергоресурсов // в трудах конференции “Коммерческий учет энергоносителей” XX1-я международная научно-практическая конференция Санкт-Петербург, май 2005, стр.277-279.

NetCore - одноплатный компьютер // материалы сайта www.Trail.ru.

InorTek µC-Series - микроконтроллеры // материалы сайта www.nevabls.ru.

Контроллеры измерительные "КОНТАР" МС8 // материалы сайта www.mzta.ru.

материалы сайта www.Prosoft.ru.

Размещено на Allbest.ru