Содержание к диссертации
Введение
ГЛАВА 1. Обзор современных систем учета тепловой энергии 14
1.1.Обзор поколений ИИС 14
1.2.Проблема автоматизации учета тепловой энергии и существующие подходы к ее решению 15
1.2.1.Интерфейсы и среды передачи данных 17
1.2.2. Система учета тепловой энергии «Взлет СП» 18
1.2.3 .Автоматизированная система «Кливер Мониторинг Энергии» 22
1.2.4.Программно-технический комплекс «КОНТАР» 24
1.2.5.Система мониторинга «Спрут-М» 27
1.2.6.3арубежные системы 29
1.3.Распространенный подход к проектированию ИИС учета тепла 33
ГЛАВА 2. Разработка архитектуры информационно-измерительной системы учета тепловой энергии общегородского масштаба 39
2.1.Требования к системе учета масштаба города 40
2.2.Разработка архитектуры информационно-измерительной системы общегородского масштаба 44
2.2.1.Сервис управления ИИС 46
2.2.2. Универсальный абстрактный протокол (УАП) 49
2.2.3.Структура классов для реализации "УАП 51
2.2.4.Структура и производительность базы данных ИИС 55
2.2.5.Возможности применения XML и XQuery в БД 61
2.2.6.Интерфейс пользователя 63
2.2.7.Взаимодействие частей программного комплекса 70
2.3 .Выводы по главе 72
ГЛАВА 3. Технологии общегородской системы учета тепловой энергии 74
3.1 .Информационно-измерительная система «КУМИР-ТеплоКом» 74
3.2. Использование сотовой связи для организации телеметрической сети учета тепла 78
3.2.1.Основные проблемы при построении сети на GPRS 78
3.2.2.Метод обратного вызова с использованием возвращенного UDP пакета 83
3.2.3.Метод обратного вызова с использованием GPRS-посредника 85
3.3.Методика создания общегородских информационно-измерительных
систем учета тепловой энергии 87
3.4.Особенности внедрения информационно-измерительной системы 90
3.5.Выводы по главе 95
ГЛАВА 4. Моделирование информационно-измерительной системы 97
4.1 .Представление ИИС как системы массового обслуживания 97
4.2.Определение функции плотности распределения времени обработки заявок 99
4.3. Имитационная модель ИИС 103
4.4.Исследование имитационной модели ПО
4.5.Практические результаты моделирования 116
Заключение 118
Список литературы 121
- Система учета тепловой энергии «Взлет СП»
- Универсальный абстрактный протокол (УАП)
- Использование сотовой связи для организации телеметрической сети учета тепла
- Имитационная модель ИИС
Введение к работе
Актуальность проблемы
Автоматизация учета тепла - одна из наиболее насущных проблем энергосбережения в России, так как идея внедрения подомового учета в ЖЬСХ потребовала установки и обслуживания очень большого числа приборов учета в рамках биллингового и технического контроля. При развертывании существующих в настоящее время систем учета тепловой энергии в масштабе города, во-первых, возрастает номинальная стоимость организации точки сбора информации, что приводит к нерентабельности развертывания таких систем, во-вторых, снижается производительность, тогда как системы масштаба города с числом приборов в несколько тысяч имеют повышенные требования к производительности и надежности, которые должны учитываться при разработке этих систем.
Происходящие и планируемые масштабные преобразования ЖЬСХ в условиях ограниченных финансовых ресурсов требуют соответствующих решений для систем диспетчеризации и учета теплопотребления. Значительное число предлагаемых для ЖКХ систем в той или иной мере копирует подходы, принятые в системах централизованного контроля промышленных предприятий. В ряде случаев применяются предназначенные для этого SCADA-пакеты, в которых акцент делается на отображении текущего технологического состояния. Применяются геоинформационные интерфейсы с нанесением текущих данных на схемы, с контролем на соответствие централизованно задаваемым установкам и т. п. Обычно такие системы ограничиваются масштабами показательного микрорайона. На практике обычно требуется обеспечить не только аварийно-диспетчерское обслуживание, на которое и ориентированы SCADA-сиетемы, но и реализовать расчет финансовых показателей работы узлов учета, сбор и обработку статистики, а также другие функции, не относящиеся к управлению режимами. Кроме того, большие общегородские системы, как правило, должны включать несколько диспетчерских пунктов, множество пользователей и разнесены территориально как по узлам учета, так и по пользователям информации.
Подход на основе SCADA-сиетем с контролем параметров в реальном времени не подходит еще и по другим причинам. Например, далеко не для всех теплосчетчиков российского производства имеются ОРС-сервера, а для которых они есть, не все поддерживают стандарт ОРС HDA — для доступа к архивам. Кроме того, ОРС-сервера работают с промышленными протоколами связи (RS232/485, Ethernet), что ограничивает их применение с нестандартными видами связи. II вообще связь в таких системах не рассматривается как часть решения, т.к. на любом производстве промышленные сети уже функционируют, либо могут быть построены для решения задач автоматизации и диспетчеризации. Строительство общегородской сети связи для автоматизации ЖКХ — решение экономически не рентабельное.
Массовая диспетчеризация иа уровне домового учета должна решать три основные задачи:
оперативно информировать о нештатных ситуациях, зарегистрированных прибором учета, а также о состоянии помещения узла (охранная, пожарная сигнализация, затопление и т. п.);
обеспечивать передачу накопленных значений для автоматизации коммерческих расчетов.
Анализировать собираемые данные с целью упрощения принятия решений.
Несмотря на большое количество публикаций и исследований информационно-измерительных систем1 в настоящее время существует разрыв между общетеоретическими исследованиями и практическими реализациями ИИС теплоучета. На сужение этого разрыва и направлена настоящая работа.
Объектом исследования являются технологии систем учета тепловой энергии.
Предметом исследования — методы построения информационно-измерительных систем учета тепловой энергии, их архитектурные особенности и способы обеспечения связи с удаленными объектами в рамках таких систем.
Целью диссертационной работы является исследование и разработка технологий создания низкозатратных информационно-измерительных систем (ИИС), работающих с большой информационной нагрузкой, разработка методов обеспечения связи с удаленными объектами в рамках таких систем и создание информационно-измерительной системы учета тепловой энергии для эффективного планирования энергосберегающих мероприятий и в перспективе для прогнозирования потребления тепловой энергии.
Основные задачи диссертационном работы состоят в следующем.
Исследование принципов организации систем }'11ета тепловой энергии: алгоритмы функционирования, структуры данных, методы передачи информации, проблемы внедрения и эксплуатации существующих систем.
Разработка архитектуры системы учета тепловой энергии, включающей наиболее распространенные средства передачи и хранения информации, обладающей высокой производительностью, а также возможностями масштабирования для наращивания емкости и функционала.
Разработка способов передачи данных от удаленных объектов по низкозатратным каналам связи GPRS, CDMA, учитывающих особенности работы этих каналов связи и использование полученных результатов в составе информационно-измерительной системы.
Создание и внедрение системы учета тепловой энергии общегородского масштаба на основе современных технологам и
1 Например, Беседин Б.А. Теория распределенных ішформационно-юмеріпелшьн систем, 1999.
сформированных в работе принципов, схем, методов и архитектуры.
Исследование работы системы на предмет максимальной емкости, производительности с использованием теории систем массового обслуживания и теории телетрафика.
Оценка возможностей системы с точки зрения дальнейшего увеличения числа узлов для учета других ресурсов.
Научная новизна работы заключается в следующем:
Предложен и реализован новый подход к созданию ИИС с территориально-рассредоточенными узлами мониторинга.
Построена имитационная модель ИИС учета тепла, позволяющая оценить влияние изменений в алгоритмах системы на ее производительность.
Предложена методика проектирования информационно-измерительных систем, работающих е большой информационной нагрузкой.
Предложены новые алгоритмы обмена телеметрической информацией между сервером и приборами учета тепла.
Разработан универсальный протокол обмена данными с тенловычислителями и способ его адаптации к реальным протоколам тешювычислителей.
Практическая ценность работы состоит в использовании, спроектировашгой в диссертационной работе информационно-измерительной системы «КУМИР-ТеплоКом», предназначенной для коммерческого и технолопгческого учета тепловой энергии, для организации общегородских или районных сетей учета тепла. Предложены и реализованы методы, позволяющие экономически-эффективно использовать GPRS для целей телеметрии. Возможно использование созданного программного комплекса для целей прогнозирования потребления тепловой энергии и информационного обеспечения энергосберегающих мероприятий. Результаты работы и рекомендации, сформированные в ней, могут быть использованы для создания аналогичных систем учета других ресурсов (холодной воды, электроэнергии, природного газа) и объединения их в универсальную бшшшговую систему. Внедрение подобных систем на территории России может способствовать формированию цивилизованных рыночных отношений между поставщиками и потребителями ресурсов, когда потребитель платит только за то, что потребляет.
Достоверность научных положении и выводов определяется исследованиями практической реализации системы учета на примере ИИС «КУМИР-ТеилоКом», внедренной на 4-х предприятиях.
В составе авторского коллектива диссертант стал лауреатом областного конкурса в сфере науки и техники в номинации «Лучшие научные, научно-технические и инновационные разработки молодых ученых (до 35 лет)» за
2008г. С разработкой «Автоматизированная система диспетчерского учета и управления энергоресурсами на основе информационно-измерительной системы «КУМИр-ТеплоКом». Апробации работы
Материалы всероссийской научно-практической конференции с международным участием «Повышение эффективности производства и использования энергии в условиях Сибири», Иркутск, ИрГТУ, 2005,2006,2007,2008,2009.
«Современные проблемы радиоэлектроники». Доклады межвузовской конференции посвященной Дню радио, 2005,2006,2007,2008,2009.
Выставка «Энергосбережение: технологии, приборы, оборудование -2008», Иркутск, СибЭкспоцентр. Выступление.
17 публикаций (4- в перечнях ВАК). Реализация результатов работы
Основные результаты работы были использованы на четырех предприятиях для организации систем коммерческого учета тепла, что подтверждено соответствующими актами внедрения:
ООО «Арманс», г.Санкт-Петербург (100 узлов учета в гг. Санкт-Петербург и Пушкин)
МУЛ «ТеплоЭнергоСервис г.Иркутска» (300 узлов по соц. сфере г. Иркутска)
ОАО «Ангарская нефтехимическая компания» (2 узла)
ООО «Комфорт», г.Иркутск (940 узлов учета ЖКХ г.Иркутска)
Публикации
По теме диссертационной работы опубликовано 17 статей, из них 4 статьи в журналах перечня ВАК, 12 статей в сборниках докладов по материалам конференций, ПО ИИС «КУМИР-ТеплоКом» зарегистрирована в государственном реестре программ для ЭВМ №200661170 от 19.05.2006г., подана заявка на «Способ передачи телеметрических данных по открытым сетям IP» (№ 2007117800/20(019380) от 14.05.2007).
Объем и структура диссертации
Система учета тепловой энергии «Взлет СП»
Ключевой особенностью всех перечисленных систем является локальный подход к проектированию. Это означает, что система разрабатывается и испытывается без учета потенциальных возможностей ее применения для координации больших размеров сетей учета. Это проявляется в инженерных решениях начиная с момента выработки структуры системы, подбора оборудования и заканчивая выбором базы данных для программного обеспечения. Действительно, какой смысл разбираться с MS SQL или Oracle, если можно взять MS Access или Firebird, - комплекс программ получится значительно дешевле, зато при разрастании сети учета простым СУБД оказывается не под силу обрабатывать 10-100Гб базы данных, падает их надежность и производительность — соответственно растет число серверов в сети, которые к тому же состоят из «недорогих компьютеров», неприспособленных для круглосуточной работы с большими объемами информации. Как следствие, высокие требования к персоналу, а главное к его количеству, что ставит под вопрос экономическую целесообразность внедрения. И самое опасное, что при начальном проектировании данному факту не придают значения, и впоследствии это оборачивается очень большими расходами одновременно со сложностями замены ИИС.
Многие разработчики изначально позиционируют ИИС, как автоматизированную систему коммерческого учета, в то время как после ее внедрения или во время внедрения может потребоваться технологический мониторинг, требующий от системы намного большей интерактивности, чем коммерче
Это приводит к невозможности удовлетворения таких требований, например, при использовании GSM-канала, ведь он не допускает распараллеливания, а соответственно на диспетчерском компьютере потребуется «повесить» не один десяток GSM-модемов, и соответственно нужен не один диспетчерский компьютер.
Еще один недостаток — это разработка чисто Ethernet-ориентированной системы. Как правило за пределами Москвы этот подход практически неприемлем ввиду отсутствия в России развитой проводной инфраструктуры связи. Ну и подход с контроллером, к которому подключаются первичные датчики, по сути являющимся тепловычислителем тоже достаточно сложен в использовании, т.к. во-первых требуется сертификация и внесение в Госреестр СИ такого контроллера, - ведь он работает с первичными измерителями, а значит влияет на точность измерений, во-вторых, в городах, как правило, уже имеется масса разных типов приборов учета, установленных без расчета на перспективы автоматизации.
Последнее представляет собой достаточно серьезную проблему, на которую разработчики информационно-измерительных систем практически не обращают внимания. В итоге, потенциальным потребителям таких систем приходится отказываться от автоматизации учета только потому, что разра ботчик не может предложить поддержку стороннего оборудования в своей системе. Те же, кто такую поддержку реализуют, - используют в основном ОРС-интерфейс для взаимодействия с оконечным оборудованием. Это приводит к ограниченности применения стороннего оборудования в системе, т.к. во-первых ОРС DA и ОРС HDA не являются кроссплатформенными интерфейсами и это автоматически заставляет разработчика выбирать Windows для реализации всей системы, во-вторых большинство ОРС серверов, которые предлагают компании-производители теплосчетчиков, обмениваются данными с теплосчетчиками либо по RS-232/485, либо по TCP/IP с использованием статического ІР-адреса, что также осложняет работу по другим протоколам. Также причиной, ограничивающей применение ОРС-стандартов для обмена данными с теплосчетчиками является то, что эти стандарты открыты только для членов организации, поддерживающей стандарт ОРС (ОРС Foundation), членство в организации платное и многие производители теплосчетчиков в России по этой причине не поставляют ОРС-сервера для своей продукции. Такое положение дел приводит к тому, что на разработчика информационно-измерительной системы ложится необходимость обеспечения взаимодействия с разными моделями теплосчетчиков, используя открытые протоколы обмена данными, предоставляемые производителями.
В странах Западной Европы и Скандинавии, где большая доля городских зданий отапливается с помощью централизованного теплоснабжения, уже реализуются крупные проекты сетей диспетчеризации отдельных кварталов и целых городов. Например, в 2005 году компанией Helsinki Energy s, которая занимается тепло- и электроснабжением финской столицы, в районах Baggble/Pakila и Berghll/Kallio 7000 электросчетчиков и 1500 теплосчетчиков датской компании Kamstrup были объединены в автоматизированную систему дистанционного считывания данных по радиоканалу [24]. Helsinki Energy планирует в течение 10 лет распространить сеть диспетчеризации на всю финскую столицу. Еще более масштабный проект в настоящее время выполняется в двух датских городах - Роскилде и Хиллерод. Здесь потребителям будет установлено 59 тысяч приборов учета, подключенных к сети автоматизированной передачи данных потребления электричества, тепла и воды. Показания с приборов в диспетчерский центр передаются посредством радио и GSM-каналов. Энергоснабжающие организации получают возможность более эффективно взаимодействовать со своими абонентами, оперативно получая сведения о расходе энергии и выставляя счета на основании этих данных.
Анализируя причины весьма малого распространения систем диспет ГЛЛВЛ І.ОСзор современных систем учета тепловой энергии черизации в нашей стране, можно указать несколько фактов. Пока мы находимся в самом начале пути внедрения приборного учета тепла. Во многих регионах еще не накоплена та «критическая масса» теплосчетчиков, при которой немедленно проявляются положительные экономические эффекты построения сетей сбора данных. Кроме того, нет определенной централизованной политики установки узлов учета на уровне крупных управляющих компаний, администраций городов и т.д. как это делается за рубежом [24], -поэтому происходит спонтанная установка тепловычислителей без предпочтения к какой-то одной модели или к какому-то производителю, а в отсутствие стандартов на передачу метрологических данных приборного учета возникают проблемы совместимости.
Универсальный абстрактный протокол (УАП)
Для обеспечения гибкости и стабильности системы все функции управления реализуются с помощью исполняемых процедур, хранящихся на сервере БД. Это позволяет оптимизировать работу сервера и избежать излишней нагрузки на соединение с БД. Кроме того, изменения в структуре управления заданиями можно производить без пересборки исходного кода сервисов системы. Объем реализации БД на MS SQL Server 2005 — 89 объектов из 4440 строк кода.
Ввиду того, что размеры таблиц с данными учета и журналом событий получаются размером в десятки и сотни миллионов записей автором было уделено особое внимание проектированию индексов на всех таблицах. Как известно, индексы в базах данных [51] можно создавать как по одному полю, так и по нескольким полям, причем при формировании запроса к БД, в котором "where" содержит несколько условий по различным полям, набор полей в запросе должен совпадать набором полей в индексе, тогда этот запрос будет выполняться быстрее [52]. Например, для таблицы BASES полями, которые используются как условия, являются следующие: dat,
Отдельный подход был применен к ключевому индексу. Как известно, индексы в современных БД подразделяются на две группы кластерные и некластерные [53]. Сервер СУБД всегда находит требуемые записи в наборе данных либо по порядковому номеру RowID, либо по индексу. Кластерный индекс (см. Рис. 10) отличается тем, что при его создании, данные индекса фактически смешиваются с хранимыми данными, таким образом, происходит упорядочение записей в наборе данных в соответствии с кластерным индексом. Это приводит к тому, что последовательная выборка данных в соответствии с индексом производится очень быстро, зато вставка данных в
Формирование кластерного индекса в БД набор сопровождается сдвигом страниц (Page Split) — операцией, потребляющей достаточно много системных ресурсов сервера. Для минимизации количества операций Page Split сервер оставляет на уровне «листьев» по одной-две свободных записи на страницу. Если требуется зарезервировать в индексе место под вставку новых данных нужно использовать опцию Fill ГЛАВА 2 Разработка архитектуры информационно-измерительной системы учета тсімовой энергииобщегородского масштаба
factor, которая показывает сколько процентов места требуется оставлять на последнем уровне индекса для вставки новых записей. По природе кластерный индекс должен быть уникальным, если все же дублирующие записи разрешены, то к ним добавляются числа из внутреннего счетчика и записи для движка СУБД остаются уникальными.
Таким образом, при проектировании кластерного индекса нужно четко знать структуру данных и структуру обращений к набору данных для которого индекс создается, чтобы соблюдался баланс между производительностью операций чтения и производительностью операций записи. Преимущество использования кластерного индекса заключается в том, что подобрав нужное значение индекса, сервер СУБД автоматически считывает данные из кластерного индекса, в случае некластерного индекса считывается указатель на данные, а чтобы считать данные требуется сделать дополнительное обращение к жесткому диску, причем две последовательно расположенные записи индекса не обязаны давать два последовательно расположенных указателя. Таким образом, в наихудшем случае на каждую запись нужно отдельное обращение к диску. В общем случае использование некластерного индекса напоминает оглавление в книге.
Рассмотрим структуру обращений к таблице BASES для которой предполагается создать кластерный индекс по нескольким полям. Как уже было сказано, отбор записей из таблицы в основном происходит по следующим полям: dat, hid, channel, a_type, dc_type. - они же обеспечивают уникальность записи. Таким образом, по ним же следует создавать индекс. Наиболее важным моментом является порядок полей в индексе, который и будет определять порядок сортировки данных. По идее этот порядок должен совпадать с порядком сортировки в запросах. Выборка же данных из таблицы производится в основном при постоянных параметрах hid, channel, a_type, dc_type и в некотором диапазоне dat. Это обусловлено тем, что необходимо видеть показания конкретного прибора (dcjype, hid), из конкретного архива (a_type) по При работе с кластерными индексами также следует помнить, что поля, входящие в них, должны иметь минимальную длину, т.к. они в качестве указателя входят в некластерные индексы. Поэтому большой кластерный индекс будет увеличивать размеры всех некластерных индексов этого-же набора данных.
В браузере должна быть включена поддержка SSL 3.0, JavaScript и Cookies — это необходимо для работы системы авторизации, а также защиты передаваемых данных от постороннего доступа. Для просмотра диаграмм и графиков в некоторых отчетах может потребоваться поддержка браузером SVG-графики и Flash, в Firefox и Opera эта поддержка встроена, для IntemetExplorer нужно установить AdobeSVGViewer. Реализация графиков посредством SVG (Scalable Vector Graphic) имеет ряд преимуществ перед генерацией растровой графики: во-первых первичный формат растровой графики — Bitmap — занимает достаточно много места в памяти и невыгоден при передаче данных, во-вторых при формировании графиков и диаграмм происходит по сути растеризация векторной графики на стороне сервера, хотя это можно с успехом сделать на стороне клиента, в-третьих при передаче растровой графики требуется ее сжатие в формат jpeg, gif или png, что приведет к дополнительным накладным расходам процессорного времени и памяти сервера. Поэтому более рациональным является использование векторного формата SVG, основанного на XML.
Использование сотовой связи для организации телеметрической сети учета тепла
Правда для ТЭМ-104 требуется прошивка с версией выше 2R.37 и в случае если прошивка устарела, ее необходимо обновить. Критичны в этом случае функции теплосчетчика, отвечающие за поиск данных на нужную дату, отсутствующие в старых прошивках, предполагающих считывание Flash полностью, а потом разборку ее данных. Понятно, что для работы через GPRS такое «общение» с прибором будет дорого стоить. Можно считать данный факт еще одним минусом в отсутствии стандартов на передачу данных от метрологического оборудования.
Однако в общем случае даже соответствие стандарту RS-232C в российских приборах учета весьма спорно.
Доработка АПИ-5 Тепловычислители КМ-5 имеют разъем DB9M, но интерфейс у них RS-485 и подключать к нему напрямую модем нельзя, - нужно использовать преобразователь интерфейса АПИ-5, который поставляется производителем тепловычислителей, но и они, как выяснилось, требуют «доработки». Она заключается в удалении дорожки на плате, ведущей к 9-му выводу DB9M. Если дорожку не удалить модем может выйти из строя. Причина тут следующая: производитель использует 9-й вывод разъема для питания портативных устройств переноса данных собственного производства. Это оправ общегородской системы учета тепловой энергии данно, если к разъему подключать только терминалы (устройства переноса данных, ноутбук), - для них этот вывод является входом и обладает достаточно большим входным сопротивлением. Для модема этот вывод является выходом и используется для уведомления терминала о входящем вызове. Сопротивление выхода, построенного по схеме «открытый коллектор» мало и при подаче на него напряжения питания (!) через этот выход будет протекать достаточно большой ток, который и вызывает перегрев интерфейсной микросхемы в модеме. Опять же подводит несоответствие стандарту! К сожалению, с этим неприятным обстоятельством пришлось столкнуться при внедрении системы в Иркутске, где более 70% парка тепловычислителей составляет КМ-5.
Тепловычислители СПТ также обладают неприятной особенностью: интерфейс RS-232 в них представляет собой 4-х контактный разъем на плате, который находится под пломбой теплоснабжающей организации, в связи с этим при монтаже разъема DB9M приходилось вызывать инспектора с теплоснабжающей организации для повторного опломбирования тепловычисли-теля. Кроме того здесь разработчик даже не заявляет о соответствии стандарту RS-232C - в документации на прибор указано «RS-232 совместимый», хотя что подразумевается под «совместимостью» со стандартом не уточняется.
В целом внедрение ИИС на предприятиях прошло успешно. На начало 2009г. Система эксплуатируется на 5 предприятиях в том числе и в ИрГТУ. Сбои в работе в основном связаны с перебоями электропитания на серверах и профилактическими работами на стороне сотовых операторов. Продолжительность таких сбоев, как правило, не превышает нескольких часов. При запуске системы после такого сбоя, данные не пропадают, они скачиваются за весь период простоя системы, за этим следит планировщик заданий.
В ближайшей перспективе планируется внедрить в сервер отчетов ГЛАВА З.Тсхнолопщ общегородской системы учета тепловой энергии возможность построения графиков, диаграмм, создать отчеты для оперативной диагностики и обеспечить поддержку принятия решений. Это обеспечит еще большую наглядность отображения данных и функциональность системы, упростит работу персонала по анализу данных теплового учета. Кроме того, система может лечь в основу комплексных систем управления зданиями в качестве ядра, предназначенного для учета ресурсов [68].
Предложенная автором во второй главе архитектура информационно-измерительной системы учета тепловой энергии, реализует концепцию коллективного учета в рамках единой общегородской информационно-измерительной системы, которая может решать гораздо более широкие задачи, чем простой коммерческий учет [69].
Как было показано в настоящей главе, реализация такой системы классическими методами коммутируемой связи (радиоканал, телефонный модем, GSM-модем) была бы немыслимой. Поэтому автором был проведен анализ основных проблем при использовании GPRS, как наиболее простого и доступного способа связи с удаленными узлами учета. Были рассмотрены существующие решения обозначенных проблем и предложены новые методы обеспечения GPRS передачи данных, имеющие преимущества при распараллеливании операций обмена данными. Объединение предложенных архитектуры и методов обеспечения связи позволило создать программный комплекс ИИС «КУМИР-ТеплоКом», обеспечивающий автоматизированный учет тепловой энергии на объектах ЖКХ и социальной сферы г.Иркутска, а также на ИТП г.Санкт-Петербурга и Ленинградской области. Всего на начало 2009г. программный комплекс обслуживал более 1500 приборов учета.
Однако учитывая постепенное распространение подомового учета других ресурсов: холодной воды, электричества, газа — следует ожидать
Технологии общегородской системы учета тепловой энергии многократного прироста количества приборов учета в общегородских сетях, кроме того постепенное внедрение поквартирного учета ресурсов в сотни раз увеличит объем накапливаемых данных. Поскольку предложенная архитектура и методы принципиально могут работать и в этих условиях необходимо достоверно оценить перспективы расширения системы количественно, ведь опосредованный учет тепловой энергии легко преобразовать к опосредованному учету других ресурсов [70] и на производительность в этом случае влияет только общее количество приборов учета. Для решения этой задачи автором была создана и исследована имитационная модель информационно-измерительной системы «КУМИР-ТеплоКом». Вопросам моделирования и посвящена следующая глава диссертационной работы.
Имитационная модель ИИС
Особенность заключается в следующем: большинство систем учета предпринимают несколько попыток связи с узлом, после чего завершают задание с указанием ошибки — узел недоступен. В этом случае диспетчер производит повторный опрос и если связи снова нет, то принимается решение о визуальном осмотре оборудования. Однако очевидно, что если связь GPRS нарушилась в данный произвольный момент времени, например, из-за пере 111
Модслирование информационно-измерительной системы грузки базовой станции оператора связи, то повторные попытки доступа не приводят к получению данных, а лишь увеличивают загрузку. Поэтому в системе реализована система динамических приоритетов [81], которая нашла отражение и в модели. Заявки в МКУ отбираются из общей очереди в соответствии с приоритетом, более новые заявки имеют приоритет перед заявками, которые система попыталась выполнить безуспешно. Кроме того, чтобы исключить постоянные повторы ошибочных заявок, когда все рабочие заявки уже были выполнены используется защитный временной интервал — 3 часа. Заявка помечается как «временно-неактивная» и указывается время активации.
Такой подход при работе с очередью как раз и приводит к тому, что ошибки связи не оказывают отрицательного воздействия на работу системы.
Ниже приводится график загрузки емкости МКУ (Рис. 28), выполняющего роль ядра в реальной системе. Как видно нагрузка также снижается при увеличении числа ошибок в системе, однако максимальная загрузка системы при 40000 теплосчетчиков в сети и числе потоков в МКУ равном 1000 находится в пределах 35%. Это означает, что ресурс системы полностью не задействован, однако уменьшение числа потоков будет неизбежно приводить к возрастанию времени нахождения задания в очереди. Поэтому необходимо проанализировать форму зависимости для времени нахождения заявки в очереди и нагрузки на МКУ от числа потоков в МКУ для определения максимального размера сети.
Результаты прогонки модели для разных значений числа потоков приведены на графиках ниже. Как и ожидалось графики имеют линейный участок, который собственно и интересен для работы системы. При работе на нелинейном участке число заданий поступивших в единицу времени превосходит число обработанных заданий за этот же промежуток времени и в общем случае очередь к такой системе будет стремиться к бесконечности [82].
Среднее время ожидания исполнения заявки — очень важный параметр систем массового обслуживания, можно даже сказать что один из ключевых. Так например, в телефонии — это время ожидания соединения в случае если все каналы станции или запрашиваемого направления заняты. В этом случае абонент по истечению этого времени получает сигнал «занято» или голосовое сообщение «направление перегружено». В компьютерных системах — это может быть время ожидания ответа сервера. Однако в любом случае, при анализе системы массового обслуживания следует определить — сколько времени умозрительно может ждать абонент.
В нашем случае заявки поступают в систему блоками с заданной периодичностью в 4 часа, поэтому все заявки должны выполниться до поступления следующей партии заявок. Стоит также отметить, что пользовательские заявки имеют абсолютный приоритет и всегда выполняются перед фоновыми заявками — это позволяет пользователю оперативно получать интересующую
Моделирование информационно-измерительной системы его информацию практически независимо от состояния процесса фонового опроса. В случае, если при поступлении новых заявок предыдущие еще не были выполнены полностью система начинает входить в режим перегрузки, что отображается наглядно на Рис. 30. Визуальная граница, с которой начинается режим перегрузки, отмечена голубой линией на уровне 67%. Таким образом, используя график полученный при моделировании, можно определить максимальную емкость телеметрической сети. При этом можно убедиться, что при максимальной нагрузке среднее время ожидания заявки приблизительно 50мин.
Моделирование іінформаціїоино-юмсрчтельной системы который будет использоваться для работы пользователей, для отложенной загрузки данных в случаях аварий на каналах связи с сервером или возможных отказах самого сервера. Кроме того, при необходимости производить опрос чаще, чем каждые 4 часа как в модели, полученная емкость сети будет кратно ниже.
Процесс построения и изучения модели ИИС, построенной по предложенной архитектуре полезен не столько с точки зрения изучения новых закономерностей в ИИС, сколько для оптимизации архитектуры самой ИИС и достижения наилучших показателей ее работы. Так, при изучении модели она неоднократно модифицировалась, соответственно при улучшении производительности вносились определенные изменения в программный комплекс. В предыдущем разделе рассматривалась только конечная версия GPSS-кода модели.
Производилась оценка работы ИИС с несколькими типами очередей (FIFO, LIFO, «приоритет ошибочных», «приоритет новых»). В результате оказалось, что наиболее эффективной дисциплиной обслуживания очереди является не FIFO, как в большинстве систем диспетчеризации, а очередь с приоритетом новых заявок. Эта дисциплина позволяет при дефиците пропускной способности МКУ обеспечить минимальную задержку в очереди для правильно работающих приборов учета, с другой стороны для приборов, у которых поврежден тракт модем-теплосчетчик или вышел из строя сам теплосчетчик данный показатель не критичен.
