CC BY
20
иркутский государственный университет путей сообщения
Белоусов Р.А., Бузиков И.А., Климов Н.Н., Фискин Е.М., Фискина М.М.
УДК 621.391.1.037.37
МОДЕЛИРОВАНИЕ И РАЗРАБОТКА ПРОГРАММНОГО КОМПЛЕКСА АВТОМАТИЗАЦИИ УЧЕТА ТЕПЛА В ЖКХ
Автоматизация коммерческого учета тепла — одна из наиболее насущных проблем энергосберегающих предприятий России. Это связано с резким увеличением числа приборов учета тепла. Идея внедрения подомового учета в ЖКХ потребовала установки и обслуживания очень большого числа приборов учета в рамках биллингового и технического контроля. При количестве приборов учета несколько сотен и даже тысяч — это непростая задача. Очевидное решение проблемы — применение различных систем автоматизации. Стандартный подход на основе SCADA-систем с контролем параметров в реальном времени здесь не подходит, так как очень сложно одновременно отобразить состояние нескольких тысяч узлов в системе, а диспетчеру сложно их проконтролировать, выявить ошибки и определить приоритетность их устранения. Однако, собрав и обработав статистическую информацию, мы получим гораздо более полную картину состояния узла учета за произвольный промежуток времени. Таким образом, автоматизация учета тепла в ЖКХ сводится не к диспетчеризации, а к автоматизации сбора и обработки статистических данных. Работа оператора в этом случае заключается в анализе подготовленных компьютером отчетов, которые отражают нештатные ситуации, позволяют оценить величину перерасхода, отклонения параметров теплоносителя от заданных. Как показывает практика, это позволяет более оперативно принимать решения.
Несмотря на наличие достаточно большого количества разработок в данной области, существующие в настоящее время системы учета тепловой энергии в случае развертывания их в масштабе города, во-первых, снижают производительность, во-вторых, возрастает номинальная стоимость организации точки сбора информации, что приводит к нерентабельности развертывания таких систем. Кро-
ме того, системы масштаба города с числом приборов в несколько тысяч имеют повышенные требования к надежности и производительности, которые должны учитываться при разработке этих систем.
Данная статья посвящена разработке масштабной информационно-измерительной системы учета тепловой энергии, позиционируемой как система массового обслуживания (СМО), возможности которой будут достаточны для создания ИИС учета тепла общегородского масштаба.
Сформируем требования к системе учета следующим образом.
1. Обеспечение связи с узлами по технологиям пакетной передачи через сети сотовой связи GPRS/CDMA/HSDPA, дающее доступ к сети в любой точке города при низкой стоимости связи, а также поддержка IP-связи в общем случае (т.е. через xDSL, Ethernet, Wi-Fi и т.д.) - это позволит использовать уже проложенные коммуникации домовых сетей на тех районах, где эти сети достаточно развиты и не дороги.
2. Множественный доступ к приборам со стороны сервера. Возможность распараллеленной обработки данных от теплосчетчиков, чтобы дать возможность получить почасовую детализацию данных даже при большом числе приборов в сети и оптимизировать работу многопроцессорных серверных систем.
3. Платформа хранения и обработки данных класса SQL Server для обеспечения возможности хранить и обрабатывать большие объемы данных, предоставляя оператору только нужные ему сведения. Это также снижает требования к каналам связи клиент-сервер.
4. Открытая платформа доступа через HTML для обеспечения возможности изменять оформление отчетных документов в соответствии с требованиями теплоснабжающих организаций, а также добавлять новые
©
УПРАВЛЕНИЕ В ТЕХНИЧЕСКИХ СИСТЕМАХ
специфичные для нужд каждой организации отчеты и интерфейсы.
5. Наличие в системе собственного WEB-сервера для предоставления доступа всем заинтересованным организациям через Интернет, возможно дополнительно использование SOAP-сервера.
6. Возможности резервирования данных и масштабирования системы.
7. Возможность выгрузки данных в формат XML для обеспечения обмена данными с другими информационными системами.
8. Автоматизация документооборота с теплоснабжающими организациями путем применения штрих-кодов на документах.
Архитектура ИИС учета тепла показана на рис.1. В соответствии с требованиями к системе, ИИС строится на технологии клиент-сервер и состоит из следующих компонентов:
- сервер базы данных — предназначен для хранения и обработки данных, поступающих через каналы связи с приборов учета тепла;
- сервис управления процессом — предназначен для реализации алгоритмов установки и управления связью и передачей данных;
- Web-Сервер отчетов — создает визуальное представление данных учета в виде таблиц, регламентированных отчетов и диаграмм, позволяет также выгружать необходимые данные в формате XML прямо через Web-интер-фейс;
- клиентские приложения — подключаются к серверу БД через локальную сеть и предназначены для конфигурирования и управления системой;
- подсистема прогнозирования — еще один сервис, предназначенный для реализа-
ции алгоритмов прогнозирования потребления тепловой энергии в масштабах отдельного объекта, района, города или конкретного теплоисточника, является частью аналитической подсистемы.
Как наиболее важный компонент системы можно выделить «сервис управления процессом», т.к. этот компонент осуществляет управление связью, синхронизацию всех терминалов, передачу данных и сверку исполняемых задач, и таким образом, определяет производительность системы, максимальное количество обслуживаемых объектов, требования к магистральным каналам связи. Функции данного сервиса разбиваются на несколько вертикальных абстрактных уровней, каждый из которых будет выполнять действия в некоторой предметной области, а также производится горизонтальное разбиение процесса на несколько одинаковых элементов для реализации распараллеливания выполнения функций передачи данных. На рис. 2 приводится архитектура сервиса управления.
Компонент «Менеджер управления опросом» производит управление созданием и уничтожением объектов с названием «Поток», выполняющихся в отдельных временных промежутках процессора и с отдельным контекстом, что позволяет оптимизировать выполнение под многопроцессорные серверные системы и за счет распараллеливания медленных операций. Функционально «Поток» содержит «Ядро» и в момент запуска подключает «Драйвер» и «Диспетчер связи». «Драйвер» выбирается на основе данных о типе тепловычислите-ля, установленного на объекте учета и выполняет преобразование уникального протокола тепловычислителя, определяемого производи-
Рис. 1. Архитектура ИСС
Рис. 2. Архитектура сервиса управления
иркутским государственный университет путей сообщения
телем оборудования в «Универсальный Абстрактный Протокол». Этот протокол реализует типовые функции обмена данными с абстрактным тепловычислителем. «Диспетчер связи» реализует унифицированный интерфейс обмена данными, не зависящий от физических способов установки соединения (ТСР, UDP, RS232/485, IPv6 и т.п.). Такая технология абстрагирования позволяет подключить к системе практически любой тепловычислитель, через любой канал связи. Использование «Диспетчера связи» позволяет строить собственные протоколы связи с телеметрическим оборудованием, что позволяет реализовы-вать алгоритмы обхода таких сетевых элементов как NAT и Firewall, достаточно часто используемых сотовыми- и интернет-операторами.
Архитектура информационно-измерительной системы масштаба города методически может исследоваться с помощью моделей теории телетрафика и теории массового обслуживания, в этом случае систему можно представить как СМО вида: D\ M | V| го | dJ. Это
система с дискретным входящим потоком заявок, экспотенциальным распределением времени обработки заявок, неограниченной очередью заявок с приоритетами на входе системы.
Ввиду достаточной сложности аналитического подхода к определению характеристик сложных систем массового обслуживания представляет интерес использование имитационных моделей. Программы имитационных
моделей на специализированных языках моделирования близки к описанию модели на естественном языке, что позволяет создавать сложные модели и изучать их характеристики без привлечения сложного математического аппарата.
Одним из наиболее эффективных и распространенных языков моделирования сложных дискретных систем является в настоящее время язык GPSS. Он может быть с наибольшим успехом использован для моделирования систем, формализуемых в виде систем массового обслуживания. В качестве объектов языка используются аналоги таких стандартных компонентов СМО, как заявки, обслуживающие приборы, очереди и т.п. Достаточный набор подобных компонентов позволяет конструировать сложные имитационные модели, сохраняя привычную терминологию СМО. Функциональная модель СМО приведена на рис.3.
Как видно из рис. 3, модель является нелинейной и содержит ветви обратной связи. Основным элементом системы является ядро. Оно должно быть представлено на GPSS многоканальным устройством (МКУ). Это объясняется тем, что логика управления опросом теплосчетчика одинакова для любого экземпляра исходного кода системы. Ядро принимает заявки до тех пор, пока есть каналы, которые могут их обслуживать. Если свободных каналов нет, заявка встает в очередь на обслуживание, при этом используется тип очереди с приоритетами. Порядок задающий приоритет, определяется по количеству ошибок опроса,
Рис. 3. Функциональная схема ИИС
©
УПРАВЛЕНИЕ В ТЕХНИЧЕСКИХ СИСТЕМАХ
которые претерпела данная заявка. Блок «Успешная обработка...», и блоки с ошибками моделируют поведение самого алгоритма опроса тепловычислителей в зависимости от получаемого результата. При этом предусматривается допуск 5% (либо 0,5%) от общего числа заявок на случай выхода из строя самого теплосчетчика или нарушения связи на линии ТС-МОДЕМ. Система в этом случае в течение 20мин. будет пытаться отправлять запросы к теплосчетчику, т.к. связь с модемом будет присутствовать. Этот интервал существенно длиннее нормального опроса (50±20сек.), поэтому данный случай значительно влияет на общую загруженность системы. В случае же ошибки связи с модемом сеанс опроса длится всего лишь 10сек., после чего заявка возвращается в очередь. Такая ситуация должна учитываться отдельно. На этапе обработки также расставляются приоритеты заявок — каждый ошибочный опрос добавляет единицу к полю приоритета заявки (параметр №1). Наивысшим считается приоритет равный нулю, т.е. более новые заявки имеют преимущество при обработке. Сама обработка задается как определенная задержка заявки во времени, задаваемая средним значением и функцией распределения.
На последнем этапе обработки делается транзакция в базу данных. Эта операция может проводиться единовременно только для одной заявки, т.к. все выходящие из ядра заявки встают в одну общую очередь без приоритетов.
Принятое в модели время равно 1мс. Моделирование ведется за 10 суток работы и позволяет учесть долгосрочные изменения в модели, например, накопление ошибок опроса при неработоспособном модеме или теплосчетчике.
По результатам моделирования можно сделать ряд выводов.
1. Число каналов в МКУ (ядре) определяет производительность системы в целом и ограничивается полосой пропускания магистрального канала связи от сотового оператора до сервера системы и составляет 1000 на
1Мбит полосы. Второе ограничение связано с загрузкой базы данных входящими транзакциями. Оно приводит к ограничению числа каналов на уровне 1500 на одно соединение с БД.
2. Система является устойчивой к помехам связи и ошибки сеансов связи на уровне 20% не приводят к заметному снижению производительности.
3. Наиболее критичным местом в алгоритме является время занятия канала при отсутствии связи с теплосчетчиком, но наличии связи с терминалом. В этом случае программой производятся повторы запросов, приводящие к длительному до 20 мин. занятию канала. Также очевидно, что следует ограничивать время пребывания таких заявок в очереди.
4. Общая производительность сети при опросе позволяет поддерживать работу с 20000 теплосчетчиков на одном сервере с магистральным каналом на GPRS сеть сотового оператора в 1Мбит/с и периодом опроса равным 4 часам.
5. Разработанная ИИС «КУМИр-Тепло-Ком» отвечает всем предъявляемым требованиям, зарегистрирована в Роспатенте и сертифицирована по системе СДС СИИИС (Программное обеспечение средств измерений и информационно-измерительных систем).
БИБЛИОГРАФИЯ
1. Белоусов Р.А., Фискин Е.М. Информационно-измерительная система «КУМИР-Теп-лоКом» - новое решение для масштабных систем автоматизации учета тепла в ЖКХ. Материалы всероссийской научно-практической конференции с международным участием «Повышение эффективности производства и использования энергии в условиях Сибири». Иркутск, ИрГТУ, 2006. С.17-18.
2. Р.А.Белоусов. Использование теории телетрафика для построения математической модели ИИС «КУМИр-ТеплоКом». Вестник ИрГТУ, 2008. С. 42-46.
3. В.В. Крылов, С.С. Самохвалова. Теория телетрафика и ее приложения. — СПб.: BHV-Санкт-Петербург, 2005. - 272 с.
