Основные программно-аппаратные элементы централизованной системы |
Возможные способы организации обмена данными системы диспетчеризации потребления энергоресурсов с объектовым оборудованием, установленным непосредственно у потребителя, определяются:
Возможны два способа установки соединения (сеанса связи с оборудованием): по инициативе сервера (т.е. сервер выполняет подключение к объектовому оборудованию), или по инициативе объектового оборудования [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, а также для обеспечения максимальной производительности сервера системы возможно использование следующих аппаратных средства и технологий:
Могут использоваться следующие клиентские приложения для организации автоматизированных рабочих мест:
Помимо использования клиентских приложений для организации автоматизированных рабочих мест, могут применяться дополнительные автономно функционирующие клиентские приложения для выполнения специализированных функций системы:
Клиентские приложения для организации рабочих мест администратора, инженеров и оператора пункта учета энергопотребления не требуют организации локальной базы данных, содержащей личные данные пользователя. Большая часть функций приложений включает настройку и диагностику состояния оборудования, а также контроль текущего энергопотребления объектов и групп объектов. Клиентские приложения должны использовать методики и алгоритмы определения и оповещения о внештатных ситуациях, определение и оповещение об отклонении энергопотребления отдельных объектов или групп объектов от номинальных значений. Архитектура клиентских приложений должна предусматривать возможность модернизации и улучшения качества работы данных алгоритмов путем модернизации только клиентских приложений, без необходимости внесения существенных изменений в остальные компоненты системы. Клиентские приложения, используемые в структурах ЖКХ, УК, ТСЖ и т. д. выполняют задачи учета энергопотребления абонентами, формирование отчетов и просмотр информации о потреблении, как отдельных абонентов, так и группы абонентов в табличном и графическом виде. Информация из базы данных или информация, полученная непосредственно с сервера используется специализированными клиентскими приложениями для интеграции с существующими системами учета энергетических ресурсов. Клиентские приложения областного центра выполняют сбор данных со всех серверов системы, т. е. их особенностью является возможность одновременной работы с несколькими серверами пунктов учета энергоресурсов. Подобная функциональность также может потребоваться в структурах ЖКХ, УК и ТСЖ, если абоненты физически подключены к разным пунктам учета энергопотребления. Для упрощения организации централизованной работы клиентских приложений в структурах ЖКХ, УК и ТСЖ может использоваться СУБД клиент-серверной архитектуры, позволяющая поддерживать одновременную работу нескольких пользователей с базой данных без необходимости постоянной синхронизации базы данных. СУБД также должна иметь средства планового резервирования и восстановление базы данных при появлении сбоев. Организация Web-интерфейса для доступа абонентов к статистике энергопотребления за определенный период требует использования дополнительных уникальных номеров, которые позволят идентифицировать абонентов сети при авторизации. Реализация Web-интерфейса подразумевает наличие Web-сервера и клиентского приложения. Web-сервер обрабатывает запросы при посещении сайта пользователями, при необходимости получения данных об энергопотреблении. Для формирования Web-страницы, сервер получает необходимые данные из БД Web-интерфейса или же запрашивает их с сервера пункта учета энергопотребления, используя клиентское приложение. В качестве СУБД возможно использование FireBird [3]. Основные преимущества системы:
Наиболее популярным свободно распространяемым кроссплатформенным Web-сервером является Apache. К преимуществам Apache также можно отнести [6]:
|