Счетчики
Рейтинг@Mail.ru
Модели основных функций, выполняемых программно-аппаратным комплексом

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

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

Функции по сбору информации о потребляемых энергоресурсах

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

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

При использовании цифрового интерфейса, периодически с заданным интервалом времени tзапр осуществляется посылка прибору запроса в установленном протоколом формате. После запроса происходит ожидание в течение времени tизм, затрачиваемого прибором (счётчиком) на преобразование текущего значения измеряемой величины, либо выдачу кода ошибки, если измерение по каким-либо причинам не было корректно выполнено. В случае, если по истечению заданного таймаута tожид ожидания ответ от прибора не был получен, то должна быть предпринята повторная попытка запроса. Если число неудачных попыток опроса превышает заданное число Nповт, то принимается решение о потере связи с прибором [1].

Целостность данных, пересылаемых по цифровому интерфейсу связи от прибора учёта контролируется при помощи контрольной суммы (CRC - Cyclic redundancy code, циклический избыточный код) которой дополняются все пакеты данных в большинстве протоколов цифровой передачи данных [1].

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

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

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


Функции по учету и хранению информации о потребляемых энергоресурсах

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

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

Общепринятыми подходами к организации хранения данных является:

  • использование систем управления базами данных;
  • использование бинарных файлов заранее определенного формата.

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

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

Основные особенности системы регистрации показаний объектового оборудования:

  • данные с объектового оборудования передаются с заданной частотой опроса;
  • показания оборудования и данные, хранимые в файлах, должны быть привязаны ко времени (т. е. должны иметь временные метки);
  • количество одновременно подключенных приборов учета энергоресурсов (счетчиков) к одному серверу может составлять несколько тысяч;
  • запросы клиентских приложений, в основном, предусматривают последовательную обработку отдельных блоков данных за указанный интервал времени (например, определить максимальное и минимальное значение величины на интервале tn≤t≤tk).

Производительность большинства современных СУБД при высокой нагрузке может оказаться недостаточной для обеспечения поддержки нескольких уже нескольких тысяч абонентов при частоте опроса порядка 1 Гц. Например, производительность СУБД FireBird в таких условиях составит порядка 1000-25000 записей в минуту. Кроме того, производительность СУБД будет снижаться при увеличении объема базы данных и поступлении клиентских запросов на выполнение обработки данных.

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

Организация резервного копирования базы данных подразумевает использование специализированных средств СУБД и требует значительных ресурсов ЭВМ при выполнении резервирования (что в свою очередь повлияет на производительности сервера).

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

Файл с первичных данных с объектового оборудования должен содержать:

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

Значение текущей измеряемой величины Xi необходимо хранить в относительных единицах для соблюдения требования использования «обезличенных» данных.

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

База данных клиентских приложений может включать:

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

Функции по преобразованию и визуализации информации о потребляемых энергоресурсах

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

В базе данных КПО находится информация о персональных данных абонента (место расположения, почтовый адрес, Ф.И.О и т.п.). Данная информация соответствует номеру объекта и позволяет однозначно идентифицировать абонента. Кроме того в базе данных КПО имеется информация о типе прибора учёта, установленного у абонента, а также масштабный коэффициент Kм который представляет собой по сути коэффициент пропорциональности, позволяющий переходить от условных чисел Nусл, получаемых с сервера к реальным значениям конкретной физической величины Xреальн , выражаемой в требуемых единицах измерения.

Функцией программы-клиента является реализация данного масштабного перехода от условных единиц к реальным физическим величинам при помощи указанного коэффициента пропорциональности. При этом имеется возможность выполнять коррекцию «нуля» поступающих от сервера данных. Коррекция нуля осуществляется путём прибавления к полученной после масштабного перехода физической величине некоторого числа ΔХ, соответствующего значению величины, принимаемому за нулевую отметку при последующих вычислениях (расчете стоимости потреблённого ресурса и т.п.). Причём значение ΔХ должно быть выражено в тех же единицах измерения, что и контролируемая величина и храниться в базе данных КПО вместе с масштабным коэффициентом Kм .

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

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

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

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

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

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

pic3

Пример отображения плана здания (этажа) с указанием места
установки устройств сбора данных и ведущих устройств.


Функции по взаимодействию с внешними абонентами и выдаче информации о потребляемых энергоресурсах

На сегодняшний день многими структурами (ЖКХ, энергосбытовые компании и пр.) активно используется разнообразное специальное программное обеспечение (например «Стек-ЖКХ», «Стек-Энерго», «1С:Предприятие» и т.п.), позволяющее выполнять расчёт стоимости энергоресурсов, потреблённых абонентами за определённый период времени. При этом чаще всего показания приборов учёта, являющиеся, по сути, исходными данными для подобных программ, необходимо заносить вручную, считывая их с квитанций об оплате, принесённых абонентами. Разработанная система мониторинга, учета и хранения информации о потребляемых энергоресурсах позволит автоматизировать данный процесс. При этом встаёт задача её сопряжения с уже существующими программами для расчёта оплаты энергоресурсов.

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

Указанные массивы значений могут быть представлены как в цифровой (бинарной) форме, так и в текстовой, либо в виде файла какого-либо стандартного формата (MS Excel, MS Word, RTF и т.п.). Текстовый формат является наиболее предпочтительным, поскольку поддерживается в качестве входного формата для импорта исходных данных большинством имеющихся на рынке программных продуктов расчета стоимости энергоресурсов. Практически все указанные программы могут получать исходные данные из файлов формата «CSV» (Comma Separated Values — значения, разделённые запятыми). Поэтому для обеспечения наилучшей совместимости и универсальности клиентские программы для сопряжения с внешними абонентами обладают функцией сохранения выборки значений по заданной группе потребителей о величине суммарного расхода энергоресурсов на требуемый момент времени в формате «CSV».

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

pic4
Схема передачи данных из системы мониторинга, учета и хранения информации о потребляемых энергоресурсах в сторонние программы (внешние абоненты), поддерживающие в качестве входного формата файлы типа «CSV».

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

Для реализации данной функции на какой-либо рабочей станции, подключенной к Интернет и имеющей фиксированный внешний IP-адрес устанавливается пакет программ, реализующих работу HTTP-сервера.

Примером подобных пакетов является один из наиболее распространённых HTTP-серверов – Apache HTTP-сервер.

Существует множество модулей, добавляющих к Apache поддержку различных языков программирования и систем разработки. В частности к ним относится модуль языка PHP (mod_php). PHP (англ. Hypertext Preprocessor - препроцессор гипертекста) представляет собой скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее он время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов [3].

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

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

pic5
Организация предоставления доступа к данным
через WEB-браузер

Функции по обеспечению защиты информации

В качестве способов повышения информационной безопасности выступают две функции – авторизация при установлении связи и шифрование передаваемых данных.

Механизм авторизации должен быть достаточно надёжным и полностью исключить подмену злоумышленниками объектового оборудования и клиентских приложений, подключающихся к центральному серверу системы учета энергоресурсов. Такое подключение и неавторизованный доступ к базе данных представляет не только риск получения сторонними пользователями информации о потреблении энергоресурсов, но и к риску потенциальной «подмены» данных о текущем энергопотреблении и нарушению нормальной работоспособности системы. Для предотвращения подобных ситуаций необходима авторизация оборудования и клиентов системы со стороны сервера.

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

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

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

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

Поскольку шифрование данных в большинстве случаев требует значительной производительности оборудования, предлагается использовать несколько алгоритмов шифрования. Наиболее ресурсоемкие алгоритмы целесообразно использовать при авторизации и обмене данными с клиентами системы, менее ресурсоемкие алгоритмы можно использовать в соединениях «сервер — объектовое оборудование».

Для хеширования в объектовом оборудовании используются циклические контрольные суммы (CRC-16), а в серверном и клиентском ПО – криптографические хэш-функции (MD5). Размер блока случайных данных, выступающего в качестве сеансового ключа шифрования, выбирается размером не менее 8 байт.

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

  • побитовое исключающее ИЛИ (XOR);
  • операции циклического сдвига на переменное число бит.
  • сложение по модулю 2.

Особого внимания требует обеспечение безопасности WEB-интерфейса. Как уже упоминалось ранее, доступ к нему осуществляется по протоколу HTTPS (Hypertext Transfer Protocol Secure) представляющему собой расширение стандартного протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается их защита.

Протокол HTTPS широко используется в мире Интернета для приложений, в которых важна безопасность соединения, например, в платежных системах. В настоящее время HTTPS поддерживается наиболее популярными Интернет-браузерами (MS Internet Explorer, Opera, FireFox, Google Chrome и др.). Он обеспечивает приемлемую защиту от атак, основанных на прослушивании сетевого соединения - от снифферских атак и атак типа man-in-the-middle (подключение злоумышленника последовательно с атакуемой линией связи) при условии, что будут использоваться требуемые шифрующие средства и сертификат сервера проверен и надёжен.

Помимо использования криптографического протокола, WEB-сервер системы учёта энергоресурсов должен быть дополнительно защищён межсетевым экраном (так называемый «брандмаузер» или «фаерволл»).

Кардинально повысить безопасность работы приложений БД позволяет защита клиентского ПО СУБД с помощью аппаратных электронных ключей (например типа «еТокеn»).

Литература

  1. Лапин А. Интерфейсы. Выбор и реализация Издательство: Техносфера 2005: стр. 168 - ISBN: 5-94836-058-X.
  2. Теория статистики / под ред. Шмойловой Р. А. - третье издание, переработанное. - Москва: Финансы и статистика, 2002. - 560 с. - 5000 экз. - ISBN 5-279-01951-8.
  3. Кузнецов М., Симдянов И. Объектно-ориентированное программирование на PHP. - Спб.: «БХВ-Петербург», 2007. - С. 608. - ISBN 978-5-9775-0142-2.
  4. Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си //Applied Cryptography. Protocols, Algorithms and Source Code in C. - М.: Триумф, 2002. - 816 с. - 3000 экз. - ISBN 5-89392-055-4.
^ Наверх