SCADA, АСУ ТП, контроллеры – основная тематика журнала «ИСУП»
Журнал «Информатизация и Системы Управления в Промышленности» публикует тематические материалы посвященные SCADA, АСУ ТП, контроллерам, автоматизации в промышленности.

Аспекты внедрения автоматизированных систем учета энергоресурсов в ЖКХ

В статье рассматриваются аспекты внедрения автоматизированных сис­тем учета на основе построенной АСКУЭ на базе АСУ и диспетчеризации АСУД‑248 производства НПО «Текон-Автоматика».



Одно из основных направлений энергетической стратегии России – способность сферы экономики эффективно использовать энергоресурсы, предотвращать нерациональные затраты на внутреннее энергообеспечение и дефицитность топливно-энергетических балансов на федеральном, региональном и муниципальном уровнях [1].

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

Доминирующим фактором нерациональных затрат являются потери, неизбежно возникающие на этапах транспортировки энергии от поставщика к потребителю.

Превращение энергии в дорогой товар выдвигает качественно новые требования к измерению и учету этого товара.

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

В связи с этим актуальной является реализация системы, которая позволила бы объединить локальные узлы учета (ЛУУ) для создания единого измерительно-информационного пространства для единовременного, непрерывного, автоматического контроля над технологическими процессами генерации, транспортировки и потребления энергоресурсов, а также организации коммерческих расчетов между поставщиками и потребителями ресурсов [2].

Сама автоматизированная система коммерческого учета энергоресурсов (АСКУЭ) в широком смысле представляет собой не только систему учета электропотребления, но и учет теплоносителя в сетях горячего водоснабжения (ГВС), отопления, а также учет расхода холодной воды (ХВС). В статье рассматриваются аспекты внедрения автоматизированных систем учета на основе построенной АСКУЭ на базе автоматизированной системы управления и диспетчеризации АСУД-248 производства НПО «Текон-Автоматика» [3].


Модель АСКУЭ

Как уже было отмечено в предыдущей статье [3], архитектуру АСКУЭ удобно рассматривать с точки зрения трехуровневой модели:
1. Уровень датчиков.
2. Уровень среды передачи данных.
3. Уровень серверов (ПК).

С точки зрения передачи данных основной информационный поток идет с первого на третий уровень.

Первый уровень объединяет ЛУУ, выполняющие первичную обработку информации (параметров расхода тепла, воды, электричества, газа и т.п.). На данном уровне выделены ПУ с импульсным выходом и ПУ с возможностью взаимодействия через интерфейсы RS-232, RS-485. Это позволяет полностью охватить как общедомовой учет, так и задачи поквартирного учета. Как правило, все водосчетчики (а также другие типы ПУ) имеют импульсный выход, а подавляющее большинство общедомовых теплосчетчиков поддерживают хорошо известный интерфейс RS-232.

Второй – определяет канал, форматы информационных обменов, способ передачи данных ПУ.
На данном уровне располагается оборудование АСУД-248, выполняющее функции устройств согласования и передачи данных (УСПД) с ПУ – это концентратор цифровых сигналов (КЦС), обеспечивающий взаимодействие по интерфейсу RS-232/485; концентратор измерителей расхода (КИР), обеспечивающий работу с импульсными ПУ.

Третий уровень совмещает в себе средства хранения, обработки и анализа данных ПУ. В задачи этого уровня входит предоставление пользователям АСКУЭ максимально объективной информации о процессах потребления энергоресурсов как отдельным объектом, так и рассматриваемой инфраструктурой в целом.
На данном уровне располагаются программные модули АСУД-248, решающие указанные задачи.


Создание общей базы данных учета энергоресурсов района

В силу того что структура районных управляющих организаций (УО) состоит из нескольких ОДС, для удобства проведения анализа данных учета энергоресурсов целесообразна организация единого сервера сбора данных (ЕССД) в рамках района. Территориально ЕССД может располагаться на территории УО, а архивы ПУ из базы данных (БД) ОДС реплицировались бы по каналам передачи данных ОДС – УО.
Под репликацией БД (от англ. replication – копирование, дублирование) понимается процесс приведения неодинаковых состояний двух и более БД со схожей структурой в одинаковое состояние.

Реализация механизма репликации локальных БД ОДС позволяет получить следующие преимущества:
- выделение более производительного ПК, нежели ПК ОДС, для обработки учетной информации;
- хранение в одном месте данных нескольких ОДС района;
- выполнение дублирования (резервирования) учетных данных;
- повышение скорости обработки информации.

Исходя из направления информационных потоков АСКУЭ, предполагается передача учетной информации только с ОДС в ЕССД. Частота передачи определяется дискретностью представления данных АСКУЭ и составляет период не менее 1 часа для архивных и не менее 10 минут для мгновенных значений ПУ. Канал связи между ОДС и ЕССД разумно строить на технологии, обеспечивающей создание локальной сети компьютеров (оптика, радиоканал и т.п.), при этом необходимо предусмотреть возможность подключения отдельных ОДС по модемным линиям. Как правило, компьютерные каналы ОДС – УО уже существуют.

Для организации ЕССД необходимо реализовать однонаправленную, вероятностную схему репликации.
Процесс репликации организован по следующему принципу:
- RServer периодически опрашивает локальные БД ОДС;
- RClient формирует файл с новыми данными ПУ, полученными с момента последней репликации;
- RServer обрабатывает файл, вносит изменения в серверную БД.

Окно приложения RServer представлено на рис. 1. В окне показаны зарегистрированные объекты репликации (ОДС), состояние канала ОДС – ЕССД, а также время последней репликации.

pic1.jpg

Рис. 1. Главное окно приложения RServer

Для снижения нагрузки на канал передачи данных программы RClient и RServer реализуют механизм потокового сжатия данных.


Взаимодействие с внешними информационными системами

Под взаимодействием будем понимать передачу (или, в общем случае, предоставление) данных АСКУЭ для их последующей обработки (производства начислений, контроля, анализа) сторонними программными средствами.
Возможные участники информационного взаимодействия представлены в табл. 1.

Таблица 1. Участники информационного взаимодействия с АСКУЭ

Таб.1.jpg

Были рассмотрены несколько вариантов представления данных учета энергоресурсов:
- генерации и передачи отчетов за определенный период в установленной форме;
- прямой доступ к БД АСКУЭ;
- реализация надстройки над БД АСКУЭ, поддерживающей унифицированный протокол.

В первом случае отчеты формируются оператором АСКУЭ с помощью программы ASUDBase, входящей в состав специализированного программного обеспечения АСУД-248 [4] в соответствии с установленным регламентом взаимодействия.

В отчетной форме на бумажном или электронном носителе информация предоставляется в адрес ЕИРЦ, энергоснабжающих (энергосбытовых) и водоснабжающих организаций, контролирующих органов.

Следует отметить, что сам процесс передачи электронного файла нормативными документами не уточняется. Это фактически приводит к различным схемам пересылки файла от передачи из рук в руки, отправке по электронной почте, до применения серверов ftp, samba и т.п. Ни о какой проверке того, что файл является именно тем файлом, который был сформирован оператором АСКУЭ, речи не идет. Устранить указанную несогласованность можно с помощью введения электронной цифровой подписи в механизм взаимодействия АСКУЭ – ЕИРЦ. Данная схема реализуема на основе теории открытых ключей [5]. После формирования файла оператор АСКУЭ подписывает его своим секретным ключом, а уполномоченный представитель ЕИРЦ перед производством расчетов проверяет целостность данных с помощью открытого ключа.

В процессе внедрения АСКУЭ приходилось также сталкиваться с просьбами о предоставлении прямого доступа к БД АСКУЭ для постоянного контроля и обновления данных ПУ сторонним программным обеспечением.

Данный способ информационного взаимодействия следует применять с максимальной осторожностью, уведомив заказчика о возможных последствиях, поскольку неверная работа стороннего приложения может привести к неработоспособности АСКУЭ в целом.

В то же время сотрудниками «Текон-Автоматика» выполняется надстройка над БД АСКУЭ, реализующая унифицированный протокол информационного взаимодействия, в виде OPC-сервера. Стандарт OPC позволяет внешним информационным системам, в том числе в режиме реального времени, получать информацию о состоянии ПУ.


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

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

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

Рассматривая информационные потоки АСКУЭ, можно выделить места, уязвимые с точки зрения информационной безопасности.

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

Участок 1. Возможные угрозы на данном этапе связаны со следующими моментами:
- искажением информации, поступившей с первичных преобразователей на ПУ (обрыв проводов, неверная установка и т.п.);
- в силу ценности частей узлов учета (термометров, манометров и т.п.) возможно их преднамеренное хищение (уничтожение);
- искажение настроек самого ПУ.

Решением проблемы является ограничение и жесткий контроль доступа в места установки ПУ. Как правило, существует возможность ограничить вход не только в подвал здания, но и оградить с помощью решеток непосредственное место установки ПУ, устраняя тем самым возможный доступ людей, имеющих право на вход в подвал, но не должных вмешиваться в работу ПУ. Следует отметить, что от 60 до 80 % угроз для любой информационной системы связаны с действиями действующих или бывших сотрудников организации. Необходимо в обязательном порядке производить опечатывание ПУ и блокировать его служебные функции для предотвращения доступа к системным настройкам.

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

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

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

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

Участок 4. Целостность и сохранность информации, передаваемой на данном участке, может быть обеспечена применением стандартных средств. Например, можно программно реализовать в приложениях поддержку протокола SSL или применить другие программно-аппаратные средства защиты информации при передаче ее по открытым компьютерным сетям [6, 7, 8]. Кроме того, должен быть обеспечен соответствующий уровень безопасности и самого ПК диспетчера ОДС, с разграничением прав доступа и т.п.

По возможности не следует объединять ПК ОДС на основе открытых сетей общего пользования (локальные городские сети доступа в Интернет) в силу высокой вирусной активности и невысокой надежности данных сетей. В противном случае рекомендуется на базе оборудования провайдера связи организация VLAN (Virtual LAN – локальной виртуальной сети), объединяющая аппаратные средства АСКУЭ в независимую среду информационного обмена.

Участок 5. В целом полностью аналогичен участку 4, за исключением того, что информационный обмен с большей вероятностью подразумевается изначально по открытым каналам связи (возможно, и с использованием Интернета), что ставит повышенные требования к идентификации, аутентификации и авторизации удаленных пользователей. Дополнительно следует максимально ограничить список доступных им функций по управлению системой.

Целесообразным считается применение VPN-решений (Virtual Private Network – виртуальные частные сети) для обеспечения должного уровня информационной безопасности.

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


Порядок ввода АСКУЭ в промышленную эксплуатацию

Жизненный цикл любой автоматизированной информационной системы состоит из 5 основных стадий [9]:
- разработка или приобретение готовой системы;
- внедрение системы;
- сопровождение программного обеспечения;
- промышленная эксплуатация системы;
- демонтаж системы.

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

Рис.2.jpg

Рис. 2. Стадии жизненного цикла автоматизированных систем


Процесс ввода АСКУЭ в промышленную эксплуатацию на конкретном объекте можно разбить на несколько этапов в соответствии с рис. 3.


Рис.3.jpg

Рис. 3. Этапы ввода АСКУЭ в промышленную эксплуатацию


Помимо указанных мероприятий, каждая устанавливаемая АСКУЭ должна быть проверена уполномоченной организацией по месту установки. В качестве организации, проводящей поверку, может выступать Всероссийский научно-исследовательский институт метрологической службы (ВНИИМС) или ФГУ «Ростест-Москва».

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

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

Только после этого АСКУЭ может законно выполнять функции коммерческого учета. Без свидетельства о поверке АСКУЭ фактически может использоваться лишь как система технологического контроля и мониторинга состояния объекта.

Фрагмент статьи в PDF

Интеграция АСКУЭ в единую общегородскую информационную систему

Текущие тенденции развития локальных специализированных информационных систем предполагают их интеграцию в общегородскую структуру мониторинга и управления.

Развитие информационных технологий и организация высокоскоростных каналов передачи данных позволили рассматривать возможность создания единой общегородской информационной системы (ЕОИС).

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

Проработка концепции создания ЕОИС началась в конце 1990-х годов для обеспечения координации действий городского управления [10, 11].

Высокая социальная и экономическая значимость информации АСКУЭ указывает на необходимость создания общегородского центра обработки данных ПУ. В задачу этой единой автоматизированной системы учета и потребления энергоресурсов (АСКУПЭ) входит интеграция данных локальных АСКУЭ различных производителей и предоставления их в пространстве ЕОИС.

Для взаимодействия различных АСКУЭ с АСКУПЭ необходима выработка общего протокола и регламента информационного взаимодействия. Это может быть:
- межбазовый обмен данными;
- разработка собственного протокола обмена данными;
- использование существующих протоколов.

Поскольку прямой доступ к БД рассматривается специалистами как крайне нежелательный, разработка собственного формата обычно является вынужденной мерой и может затруднить добавление в систему нового оборудования, желательно использование общепринятого стандарта. В силу того что на уровне АСКУПЭ подразумевается наличие высококвалифицированного обслуживающего персонала, рекомендуется строить взаимодействие на основе стандарта OPC.

Технология OPC (OLE for Process Control) разрабатывалась с учетом взаимодействия гетерогенных (неоднородных) систем [12]. Согласно концепции OPC, оборудование нижнего уровня подключается к системе верхнего уровня (OPC-клиент) через программный шлюз (OPC-сервер), имеющий стандартизированный протокол обмена данными. При таком подходе задача подключения нового оборудования любого производителя к системе сводится к локальной задаче настройки шлюза OPC-клиент / OPC-сервер.

Наличие OPC-сервера является гарантией совместимости любого устройства с любой современной SCADA-системой, которая может быть использована на верхнем уровне АСКУПЭ.


Литература

1. Энергетическая стратегия России на период до 2020 года. Утв. распоряжением Правительства РФ № 1234-р: [принят от 28.03.2003].
2. Иванов А.С. Внедрение автоматизированных систем учета энергоресурсов в жилищно-коммунальном хозяйстве // Вестник поморского университета. Серия «Естественные и точные науки». Архангельск: ПГУ им. Ломоносова, 2006. С. 179–182.
3. Иванов А.С., Тарасенков М.А., Лукичев А.Ю., Серов И.В., Грудин Д.В. Построение системы АСКУЭ на базе автоматизированной системы диспетчеризации АСУД-248 // Информатизация и системы управления в промышленности. М., 2006. С. 4–13.
4. ASUDBase (программа интерпретации учетных данных): Свидетельство об официальной регистрации программы для ЭВМ № 2006612658 РФ / Иванов А.С. (РФ); ООО НПО «Текон-Автоматика».
5. Романец Ю.В., Тимофеев П.А., Шаньгин В.Ф. Защита информации в компьютерных системах и сетях / Под ред. В.Ф.Шаньгина. М.: Радио и связь, 1999. 328 с.
6. Зима В.М. и др. Безопасность глобальных сетевых технологий. СПб.: BHV, 2001. 320 с.
7. SSL 3.0 Specification / http://wp.netscape.com/eng/ssl3
8. Stunnel ‑ Universal SSL Wrapper / http://www.stunnel.org
9. Ефимов Г. Жизненный цикл информационных систем // Сетевой: эл. журн. ЗАО «Издательский дом мировой периодики», 2001. № 2; http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44
10. Проект «Информационная Сеть жилищно-коммунального хозяйства города»: Предварительное ТЭО. 3-я ред. М., Зеленоград, 1998. 32 с.
11. Росаткевич Г.К., Краснобаев В.В. Единая автоматизированная система диспетчерского контроля и управления городским хозяйством на базе московской волоконно-оптической сети // Энергосбережение. М.: АВОК, 1999. № 5;
www.abok.ru/for_spec/articles.php?nid=211
12. Мартынов Ю.И. Применение SCADA-систем для построения программного обеспечения АСУ энергетикой промышленных предприятий // Проблемы и перспективы прецизионной техники и управления в машиностроении / ИПТМУ РАН. Саратов: СГТУ, 2002. С. 57–5




Статья опубликована в журнале «ИСУП», № 2(32)_2011

А.С. Иванов, к.т.н., заместитель начальника отдела программирования;
А.С. Дмитриев, к.т.н., директор по науке,
тел.: (495) 971-4121,
e-mail:tekon@tekon.ru