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

Рассмотрим менее драматическую ситуацию. Нужно поменять те или иные параметры системы. Грамотно построенная программа управления предоставит такую возможность, но только по месту установки контроллера. Т.е. специально обученный человек должен поехать к нужному дому и в недрах подвала отыскать контроллер, на дисплее которого найти нужный параметр и изменить его. Через неделю становится известно, что смена параметра привела не к тем последствиям, которые ожидали, и нужно еще раз провести корректировку. Тот же самый обученный человек (если он не в отпуске и не на больничном) едет в тот же дом и снова меняет значение параметра. И так может продолжаться долго…очень долго. А теперь учтем, что у эксплуатирующей организации есть не один дом, а сто. И сколько нужно тогда специально обученных людей, машин и времени на то, чтобы корректировать настройки всех систем. А если нужно поменять не один параметр, а временную программу (расписание)?

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

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

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

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

Пример 1. Локальная диспетчеризация.
Пример 1. Локальная диспетчеризация:


Назначение	Обеспечение локального управления системой
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий открытый протокол LON (Panther, Tiger, Lion, Serval, Lynx); LON интерфейс для компьютера (PCLTA-21, PCC10, NIC709-USB); Программное обеспечение ARENA (CLAR2SL10 или CLAR2SL99 в зависимости от количества точек).
Область применения	- Локальные объекты, не требующие удаленного доступа.


Пример 2. Локальная диспетчеризация с возможностью удаленного доступа(протоколы LON и LAN).
Пример 2. Локальная диспетчеризация с возможностью удаленного доступа(протоколы LON и LAN):


Назначение	Обеспечение локального и удаленного управления системой на базе протоколов LON и LAN
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий открытый протокол LON (Panther, Tiger, Lion, Serval, Lynx); LON интерфейс для компьютера (PCLTA-21, PCC10, NIC709-USB); Программное обеспечение ARENA (CLAR2SL10 или CLAR2SL99 в зависимости от количества точек).
Область применения	- Локальные объекты, состоящие из нескольких корпусов, расстояние между которыми (или количество точек которых) не позволяет использовать только LON для передачи данных; - Территориально распределенная сеть объектов, допускающая построение LAN сети.


Пример 3. Локальная диспетчеризация с возможностью удаленного доступа(протоколы C-Bus и LAN).
Пример 3. Локальная диспетчеризация с возможностью удаленного доступа(протоколы C-Bus и LAN):


Назначение	Обеспечение локального и удаленного управления системой на базе протоколов C-Bus и LAN
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий протокол C-Bus (Panther, Lion); BNA адаптер CLIF-CBUS; Программное обеспечение ARENA (CLAR2SD99) + CLAR2DRV-CBUS.
Область применения	- Локальные объекты, использующие протокол C-Bus - Локальные объекты, состоящие из нескольких корпусов, расстояние между которыми (или количество точек которых) не позволяет использовать только C-Bus для передачи данных; - Территориально распределенная сеть объектов, допускающая построение LAN сети.


Пример 4. Диспетчеризация с возможностью удаленного доступа.
Пример 4. Диспетчеризация с возможностью удаленного доступа:


Назначение	Обеспечение удаленного управления системой на базе протоколов LON и LAN
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий открытый протокол LON (Panther, Tiger, Lion, Serval, Lynx); LON – LAN преобразователь iLON10; Программное обеспечение ARENA (CLAR2SD99). Модем.
Область применения	- Территориально распределенная сеть объектов, не допускающая построение LAN сети, а требующая организации модемной связи


Пример 5. Комбинация локального и удаленного подключения на основе протоколов LON и LAN.
Пример 5. Комбинация локального и удаленного подключения на основе протоколов LON и LAN:


Назначение	Обеспечение удаленного управления системой на базе протоколов LON и LAN, а так же модемной связи
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий открытый протокол LON (Panther, Tiger, Lion, Serval, Lynx); LON – LAN преобразователь iLON10; Программное обеспечение ARENA (CLAR2SD99 + CLAR2DRV-A2A). Модем.
Область применения	- Территориально распределенная сеть объектов, допускающая построение LAN сети, с возможностью использования модемной связи.


Пример 6. Комбинация локального и удаленного подключения на основе протоколов C-Bus и LAN.
Пример 6. Комбинация локального и удаленного подключения на основе протоколов C-Bus и LAN:


Назначение	Обеспечение удаленного управления системой на базе протоколов LON и LAN, а так же модемной связи
Принципиальная схема
Необходимое аппаратное и программное обеспечение	Контроллер, поддерживающий открытый протокол LON (Panther, Tiger, Lion, Serval, Lynx); LON – LAN преобразователь iLON10; BNA адаптер CLIF-CBUS; Программное обеспечение ARENA (CLAR2SD99 + CLAR2DRV-CBUS+ CLAR2DRV-A2A); Модем.
Область применения	- Территориально распределенная сеть объектов, допускающая построение LAN сети, с возможностью использования модемной связи.

Не последнее место в системе диспетчеризации занимает визуализация.
Хорошо продуманная «картинка» и интерфейс:

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

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

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

К каждому объекту можно привязать ту или иную переменную. Строго говоря, привязка происходит не к самому объекту, а к какому-либо из его свойств. Например привязка значения температуры к свойству «ВИДИМОСТЬ» рисунка снежинки. Так можно добиться эффекта «заиндевения» краев экрана при понижении температуры (очень популярный визуальный эффект в Западной Европе).

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

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

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

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

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

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

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

Решить поставленную задачу на оборудовании CentraLine AX очень легко. Мультипротокольная платформа HAWK поддерживает работу с большинством известных протоколов (включая OPC), избавляя, таким образом, от использования нескольких шлюзов, а программное обеспечение ARENA AX позволяет:

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