Архитектура сети интеллектуальных контроллеров в здании

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

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

Если управление всеми подсистемами замкнуто на один компьютер (а), то его авария приводит к сбою всей системе. Распределенная архитектура более устойчива (б) (рис. 18.3).

Рис. 18.3. Схема управления подсистемами

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

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

Ниже приведена система управления интеллектуальным зданием (рис. 18.4).

Рис. 18.4. Интеллектуальное здание в приблизительном многоуровневом исполнении

Завершая разговор на тему о правильных и неправильных решениях, хотелось бы остановиться на роли корпоративной сети передачи данных в системе ИЗ. То, что она должна использоваться, сомнению не подлежит, вопрос только ¾ как? Если сеть служит для обмена данными между управляющим компьютером (или компьютерами) и отдельной сетью интеллектуальных контроллеров, то никаких проблем нет.

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

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

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

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

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

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