Печать
Категория: Статьи

Автоматизация коммерческого учета тепла – одна из наиболее насущных проблем энергосберегающих предприятий России. Это связано с резким увеличением числа приборов учета тепла. Идея внедрения подомового учета в ЖКХ потребовала установки и обслуживания очень большого числа приборов учета в рамках биллингового и технического контроля. При количестве приборов учета несколько сотен и даже тысяч – это непростая задача. Однако, собрав и обработав статистическую информацию, мы получим полную картину состояния узла учета за произвольный промежуток времени.

Таким образом, автоматизация учета тепла в ЖКХ сводится не к диспетчеризации, а к автоматизации сбора и обработки статистических данных. Работа оператора в этом случае заключается в анализе подготовленных компьютером отчетов, которые отражают нештатные ситуации, позволяют оценить величину перерасхода, отклонения параметров теплоносителя от заданных. Как показывает практика, это позволяет более оперативно принимать решения.

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

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

Сформируем требования к системе учета следующим образом:

Архитектура ИИС учета тепла показана на рис.1. В соответствии с требованиями к системе, ИИС строится на технологии клиент-сервер и состоит из следующих компонентов:

Как наиболее важный компонент системы можно выделить «сервис управления процессом», т.к. этот компонент осуществляет управление связью, синхронизацию всех терминалов, передачу данных и сверку исполняемых задач, и таким образом, определяет производительность системы, максимальное количество обслуживаемых объектов, требования к магистральным каналам связи. Функции данного сервиса разбиваются на несколько вертикальных абстрактных уровней, каждый из которых будет выполнять действия в некоторой предметной области, а также производится горизонтальное разбиение процесса на несколько одинаковых элементов для реализации распараллеливания выполнения функций передачи данных. На рис. 2 приводится архитектура сервиса управления.

Компонент «Менеджер управления опросом» производит управление созданием и уничтожением объектов с названием «Поток», выполняющихся в отдельных временных промежутках процессора и с отдельным контекстом, что позволяет оптимизировать выполнение под многопроцессорные серверные системы и за счет распараллеливания медленных операций. Функционально «Поток» содержит «Ядро» и в момент запуска подключает «Драйвер» и «Диспетчер связи». «Драйвер» выбирается на основе данных о типе тепловычислителя, установленного на объекте учета и выполняет преобразование уникального протокола тепловычислителя, определяемого производителем оборудования в «Универсальный Абстрактный Протокол». Этот протокол реализует типовые функции обмена данными с абстрактным тепловычислителем. «Диспетчер связи» реализует унифицированный интерфейс обмена данными, не зависящий от физических способов установки соединения (ТСР, UDP, RS232/485, IPv6 и т.п.). Такая технология абстрагирования позволяет подключить к системе практически любой тепловычислитель, через любой канал связи. Использование «Диспетчера связи» позволяет строить собственные протоколы связи с телеметрическим оборудованием, что позволяет реализовывать алгоритмы обхода таких сетевых элементов как NAT и Firewall, достаточно часто используемых сотовыми- и интернет-операторами.

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

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

Рисунок 3: Функциональная схема ИИС

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

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

Как видно из рисунка, модель является нелинейной и содержит ветви обратной связи. Основным элементом системы является ядро. Оно должно быть представлено на GPSS многоканальным устройством (МКУ). Это объясняется тем, что логика управления опросом теплосчетчика одинакова для любого экземпляра исходного кода системы. Ядро принимает заявки до тех пор, пока есть каналы, которые могут их обслуживать. Если свободных каналов нет, заявка встает в очередь на обслуживание, при этом используется тип очереди с приоритетами, порядок которой задается приоритетом, определяемым по количеству ошибок опроса, которые претерпела данная заявка. Блок «Успешная обработка…», и блоки с ошибками моделируют поведение самого алгоритма опроса тепловычислителей в зависимости от получаемого результата. Здесь мы предусматриваем допуск 5% (либо 0,5%) от общего числа заявок на случай выхода из строя самого теплосчетчика или нарушения связи на линии ТС-МОДЕМ. Система в этом случае в течение 20мин. будет пытаться отправлять запросы к теплосчетчику, т.к. связь с модемом будет присутствовать. Этот интервал существенно длиннее нормального опроса (50±20сек.), поэтому данный случай значительно влияет на общую загруженность системы. В случае же ошибки связи с модемом сеанс опроса длится всего лишь 10сек., после чего заявка возвращается в очередь. Поэтому этот случай мы также учитываем отдельно. На этапе обработки также расставляются приоритеты заявок – каждый ошибочный опрос добавляет единицу к полю приоритета заявки (параметр №1). Наивысшим считается приоритет равный нулю, т.е. более новые заявки имеют преимущество при обработке. Сама обработка задается как определенная задержка заявки во времени, задаваемая средним значением и функцией распределения.

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

Принятое в модели время равно 1мс. Моделирование ведется за 10 суток работы и позволяет учесть долгосрочные изменения в модели, например, накопление ошибок опроса при неработоспособном модеме или теплосчетчике.

По результатам моделирования были сделаны следующие выводы: