Мониторинг
малых объектов теплоэнергетики (на примере,
ЦТП и бассейна ВДЦ “ОКЕАН”)
Гербек Ф.Э., м.н.с.
Даниельян
С.А., инж.-прогр.,
Раздобудько
В.В., инж.-прогр.,
Чипулис В.П., зав.лаб.,
д.т.н., проф.,
ИАПУ ДВО РАН, г.
Владивосток
Одна
из основных задач, требующих решения в процессе создания систем мониторинга и
диспетчеризации технических объектов, связана с выбором адекватных масштабу проекта
программных и аппаратных средств автоматизации. От выбора тех или иных
инструментальных средств в большой степени зависит как программно-техническая
архитектура проекта, так и. его стоимость.
Существует
несколько подходов к созданию программой части информационной системы. Один из
них – использование SCADA-систем [2]. Этот подход обладает значительными преимуществами
при создании средних и больших систем, т.к. в SCADA-системе уже реализованы
алгоритмы опроса приборов, графическая подсистема, коммуникационная подсистема,
организующая связь между узлами распределенной системы; алгоритмы управления и
многие другие функции [3]. Таким образом, благодаря SCADA-системе отсутствует
необходимость реализации этих подсистем. С другой стороны, если речь идет о
небольших объектах, стоимость исполнительных модулей, необходимых для работы
программного обеспечения, основанного на SCADA-системе, сравнима с бюджетом
всего проекта. Кроме того, если в проекте не предусмотрено управление объектом
и в его составе имеется только один узел, используется минимум возможностей
SCADA-системы. Другая важная особенность SCADA-системы – наличие в ее составе
СУБД реального времени [1]. СУБД-РВ обладает коротким временем отклика и
позволяет оперативно сохранять информацию о быстро протекающих процессах с
многих точек измерения. Поскольку процессы в теплоэнергетике обладают большой
инерционностью, а количество точек измерения на небольших объектах
незначительно, с задачей архивирования для таких объектов вполне может справиться
СУБД общего назначения. Дополнительно облегчить работу СУБД может использование
приборов со встроенными архивами усредненных значений.
Разработка
программного обеспечения информационной системы с помощью традиционных средств
программирования, напротив, связана с самостоятельной реализацией всех подсистем,
что требует более высокой квалификации программистов и приводит к возрастанию
временных затрат. С другой стороны, программные модули, реализованные в составе
одного проекта, в последствии могут быть использованы и в других аналогичных
проектах, если такая возможность будет заложена на этапе их разработки. Таким образом, затраты на
начальном этапе могут быть скомпенсированы при разработке последующих проектов.
Руководствуясь
изложенными выше соображениями при создании программного обеспечения
информационной системы ЦТП ВДЦ “Океан” (рис. 1) были использованы традиционные средства
программирования – компилятор C++ и СУБД общего назначения. В процессе выбора
СУБД для основного хранилища данных был проведен ряд экспериментов, показавших,
что временные характеристики доступа к данным СУБД MySQL в полной мере соответствуют
требованиям проекта. Принимая во внимание тот факт, что MySQL бесплатен, а так
же широко распространен, мы остановили выбор именно на этой СУБД.
рис.
1. Окно программы мониторинга ЦТП ВДЦ “Океан”
На начальном этапе был определен ряд задач, которые
должна решать система в процессе работы. К этим задачам в первую очередь
относится сбор информации с приборов и запись ее в базу данных, вывод на экран
дисплея мнемосхемы ЦТП, отображающей технологическое оборудование с
установленными на нем контрольно-измерительными приборами, визуализацию
значений измеренных величин по точкам измерения в реальном времени,
отслеживание и указание на экране выхода значений измерений за пределы технологического
диапазона, построение графиков по архивным значениям, сохраненным в базе
данных; генерация отчета.
В процессе проектирования были проанализированы связи
между вышеперечисленными задачами и на основании этого сделан вывод о том, что
они разделяются на группы, связанные между собой только через базу данных.
Более того, эксплутационные требования к отдельным группам задач значительно
различаются. Наиболее логичным решением в данном случае является реализация
информационной системы в виде нескольких независимых программ:
·
Подсистема сбора и
архивации данных;
·
Подсистема
мониторинга;
·
Подсистема
ретроспективного анализа данных и генерации отчетов;
Подсистема сбора и архивации данных осуществляет сбор
текущих и архивных данных с приборов и запись их в базу данных. Эта программа
реализована в виде программного сервера, не имеет пользовательского интерфейса
и предназначена для автономной работы. Таким образом, она может устанавливаться
как на отдельный компьютер, так и совместно с другими подсистемами.
Конфигурация приборов и набор считываемых параметров
задается в базе данных. Так же в конфигурационной таблице задается
периодичность опроса текущих и архивных значений измеряемых параметров. На
верхнем уровне опрос приборов ведется посредством двух независимых потоков –
один для текущих, а другой для архивных данных. На нижнем уровне процедура
опроса запускает отдельные потоки на каждый COM-порт. Для предотвращения одновременного
доступа к COM-порту из разных потоков используется массив флагов блокировок.
Процесс считывания текущих данных отличается от
считывания архива тем, что текущие данные не накапливаются в базе. При
поступлении очередных текущих данных старые текущие записи, относящиеся к
соответствующим параметрам, удаляются из базы данных. Это позволяет избежать
неконтролируемого увеличения базы данных.
Каждый элемент данных, как архивных, так и текущих,
привязывается к времени. Для текущих данных в базу записывается время
считывания, а для архивных – время, к которому они привязаны в архиве прибора.
Подсистема мониторинга предназначена для отображения
результатов измерения, а так же своевременного обнаружения и предупреждения о
нештатных ситуациях. Программа отслеживает два вида нештатных ситуаций – выход
значения за установленные пределы и устаревание текущих данных. В первом случае
программа выделяет информационное окно со значением посредством красной рамки и
выдает звуковой сигнал. Во втором случае – информационные окна помечаются серым
цветом как неактивные.
Подсистема мониторинга получает значения измерений из
базы данных в соответствии с периодом обновления, заданным в конфигурационной
таблице. Параметры доступа к базе данных задаются в текстовом конфигурационном
файле, доступ к базе данных осуществляется посредством TCP/IP. Таким образом,
подсистема мониторинга может работать как на одном компьютере с СУБД, так и на
разных компьютерах. Кроме того, с одной базой данных могут работать несколько
копий подсистемы мониторинга, установленных на разных компьютерах.
рис.
2. Подсистема ретроспективного анализа данных (графики температуры
теплоносителя)
Подсистема ретроспективного анализа данных (рис. 2)
предназначена для обработки и отображения информации из базы данных в виде
графиков, таблиц и отчётных форм. Подсистема позволяет просматривать графики
измеренных величин, а так же графики величин, вычисляемых на основе измеренных,
например, разность температур, разность расходов, скорость изменения расходов и
т.д. Формулы для графического отображения значений вычисляемых параметров
задаются пользователем и полученные с помощью формул ряды данных могут быть
запомнены в программе. Для удобства просмотра предоставляется возможность
выделения групп параметров с последующим их запоминанием. Ряды данных по
группам параметров могут быть также выведены в виде таблиц.
Возможность вывода разнородных данных (например,
температуры и количества теплоты) на один и тот же график, но на разные оси
позволяет, в частности, визуально оценить корреляцию между этими данными.
Иногда бывает полезным сравнить данные за разные периоды. Например, сравнить
расходы теплоносителя за одни и те же месяцы в разных отопительных сезонах. С
этой целью предусмотрен вывод графиков за выбранные периоды на разные оси времени,
совмещённые этими периодами.
Кроме этого в подсистеме имеется возможность усреднения
данных за произвольно выбранные периоды (несколько часов, сутки, месяц и т.д.),
а также вывод средних значений по периодам, например, средние по часам суток,
по дням недели и т.д.
Наиболее важная функция подсистемы ─ анализ
теплового режима функционирования объекта. Здесь анализируются отклонения реальных
данных от нормативных и таким образом производится контроль оптимальности
параметров для данного режима функционирования объекта.
Пользователь или администратор системы может настроить
ее под конкретный объект: определить отображаемые параметры, сформировать
группы параметров, ввести формулы для расчёта вычисляемых параметров.
Предусмотрена так же возможность
перенастройки системы в случае каких либо технологических изменений на
объекте.
Результатом анализа данных является отчёт, который
автоматически формируется программой. Форма отчёта может быть настроена
пользователем или администратором системы, а именно, ориентация страницы,
«шапка» отчёта, поля сводных данных, имя составителя и т.д. Сводные данные
могут быть заданы формулами.
рис.
3. Окно программы мониторинга бассейна ВДЦ “Океан”
Программное обеспечение, разработанное в рамках проекта
информационной системы ЦТП ВДЦ “Океан”, в последствии позволило с минимальными
временными затратами реализовать информационную систему бассейна ВДЦ “Океан”
(рис. 3).
Дальнейшее развитие проекта – проводящаяся в настоящее
время разработка единой диспетчерской системы ВДЦ “Океан”. Программное
обеспечение диспетчерской разрабатывается с использованием SCADA-системы TRACE MODE 6. Также, в рамках этого проекта выполняется замена
разработанного ранее программного обеспечения мониторинга котельной на
информационную систему, разработанную на основе TRACE MODE 6. Для того
чтобы связать программное обеспечение системы мониторинга бассейна и ЦТП с единой
диспетчерской, был разработан специальный драйвер для TRACE MODE 6,
позволяющий получать текущие данные из БД MySQL в режиме
реального времени.
Таким образом, был создан программный продукт,
обладающий масштабируемостью и универсальностью, достаточными для создания
информационных систем малых объектов теплоэнергетики. При этом универсальность
была достигнута без значительного усложнения программного обеспечения. Высокая
степень модульности, а также простота программ, входящих в состав системы,
сделали возможным проведение комплексного тестирования и отладки системы.
Разделение программного обеспечения системы на
отдельные модули, связанные между собой посредством базы данных, позволяет
использовать разработанное программное обеспечение для создания распределенных информационных
диспетчерских систем различной конфигурации (в том числе гетерогенных систем,
отдельные части которых разработаны с использованием различных технологий,
таких как SCADA-системы).
Литература
1.
Горин А.,
Каневский А. Базы данных реального времени в системах автоматизации производства
// Промышленные АСУ и контроллеры. М.
“Научтехиздат” №12, 2003г.
2.
Бунин В.,
Анопренко В., Ильин А., Салова О., Чибисова Н., Якушев А. SCADA-системы:
проблема выбора // СТА. 1999. №4
3.
TRACE MODE 5 руководство пользователя // AdAstra Research Group. М., 2003 г.