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

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

Возможны два способа установки соединения (сеанса связи с оборудованием): по инициативе сервера (т.е. сервер выполняет подключение к объектовому оборудованию), или по инициативе объектового оборудования [5].

В первом случае существенно усложняется способ подключения к оборудованию, особенно  при использовании динамического распределения адресов объектов в системе (например, при использовании каналов GPRS, системы DHCP в сетях Ethernet и WiFi) [5, 6]. В ряде случаев (например, при использовании маршрутизаторов NAT и сетевых экранов) установление подключения к оборудованию со стороны сервера становится практически невозможным или приводит к необходимости индивидуальной настройки сетевого оборудования для доступа к каждому из устройств системы. Кроме того, существенно усложняются процедуры перенастройки, модернизации и замены объектового оборудования и вспомогательного сетевого оборудования, поскольку придется выполнять настройку, как сервера, так и объектового оборудования.

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

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

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

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

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

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

Для обеспечения защиты передаваемых данных по общедоступным каналам связи и исключения возможности «подмены» объектового оборудования необходимо использовать процедуру авторизации при установке сеанса связи с устройством и исключение возможности несанкционированного доступа к объектовому оборудованию [1].

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

Архитектура сервера системы должна предусматривать:

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

Таким образом, в архитектуре сервера можно выделить:

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

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

Для поддержания нормальной работоспособности при большом количестве абонентов необходимо использовать высокопроизводительное сетевое оборудование (например, стандарта Ethernet-100, Ethernet-1000).

Для обеспечения максимальной скорости записи поступающих данных, и уменьшения времени запроса клиентских приложений при большом количестве абонентов целесообразно использовать RAID-контроллеры. Это позволит как увеличить скорость доступа к данным (особенно в режиме RAID-0), так и доступный объем дискового пространства.

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

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

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

Наиболее подходящими с позиций распространенности и удовлетворяющие требованиям производительности сервера являются операционные системы серии Windows Server, а также операционные системы на базе ядра Linux. Использование ОС Linux предусматривает более широкие возможности в настройке производительности, как операционной системы, так и оборудования, а так же является свободно распространяемой ОС.

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

Максимальные требования надежности работы предъявляются, в основном, к центральному серверу системы и объектовому оборудованию, т. к. они должны обеспечивать постоянную работоспособность и стабильную работу в реальном масштабе времени.

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

• организация многопотокового приложения для увеличения производительности в многоядерных и многопроцессорных системах;
• использование высокопроизводительного сетевого оборудования;
• использование высокопроизводительных дисковых устройств с применением RAID-контроллеров;
• организация сетевого обмена по протоколам TCP/IP;
• использование файлов для организации структуры базы данных, поскольку аналитический анализ информации выполняется в основном с использованием клиентских приложений, в то время как сервер выполняет только первичную обработку информации [2].

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

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

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

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

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

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

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

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

Для упрощения организации централизованной работы клиентских приложений  в структурах ЖКХ, УК и ТСЖ может использоваться СУБД клиент-серверной архитектуры, позволяющая поддерживать одновременную работу нескольких пользователей с базой данных без необходимости постоянной синхронизации базы данных. СУБД также должна иметь средства планового резервирования и восстановление базы данных при появлении сбоев.

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

В качестве СУБД возможно использование FireBird [3]. Основные преимущества системы:

• является свободно распространяемым кроссплатформенным приложением с открытым исходным кодом;
• поддерживает широкие возможности организации одновременного доступа к данным из нескольких независимых приложений;
• обладает широкими возможностями по созданию дополнительных процедур обработки данных на уровне СУБД по сравнению с другими свободно распространяемыми СУБД.

Наиболее популярным свободно распространяемым кроссплатформенным Web-сервером является Apache. К преимуществам Apache также можно отнести [6]:

• безопасность приложения;
• поддержка динамической генерации Web-страниц;
• поддержка технологии CGI, что позволит упростить реализацию функций сервера с использованием клиентских приложений;
• наличие полноценной поддержки СУБД FireBird.

Литература