«ОБЛАСТИ» - СОВРЕМЕННЫЙ ПОДХОД К НАСТРОЙКЕ СИСТЕМ

Скачать

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

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

Проблема, разумеется, не нова. Уже старые неадресные 20-ти или 40-ка шлейфовые приборы ставили эту задачу перед разработчиком. Разделы, зоны, группы – применялись различные термины, и у всех этих терминов есть свои особенности. Мы стали использовать термин «область», чтобы подчеркнуть геометрический, территориальный принцип разбиения системы на части. В системе «Рубикон» область, как правило, соответствует одному или нескольким помещениям.

В чем особенность подхода «Рубикон» ?

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

Вторая особенность – возможность строить иерархические списки областей. Типичная ситуация – здание состоит из нескольких этажей, на каждом этаже есть коридор и несколько комнат. Строите иерархическую структуру, затем, например, ставите на охрану область «здание» - и автоматически ставятся на охрану все входящие в нее области «этаж» и, соответственно, «комната». Даете оператору полномочия управлять областью «этаж 2» - и, соответственно, он имеет полномочия управлять всеми комнатами на этом этаже (если явно не добавлено специальное правило-исключение типа «запретить управление комнатой 217»). Обратите внимание, говоря умными словами, формально структура взаимосвязи областей не обязана быть графом типа «дерево». Простыми словами то же самое можно выразить иначе: совсем не обязательно у всех областей должен быть только один родитель, и уж тем более необязательно, чтобы все области входили в какую-то структуру, могут быть отдельные области, или группы связанных областей, никак не увязанных с остальными областями. Единственное ограничение – не стоит пытаться построить «закольцованную» структуру, например «А входит в В, В входит в С, а С входит обратно в А» - такая структура не приведет (скорее всего) к полному краху и зависанию системы, но функционирование таких цепочек областей, мягко говоря, трудно предсказать.

Стоит отметить некоторые следствия построения системы «Рубикон» вокруг областей. Так, скрипты (программируемые пользователем последовательности действий) удобно делать универсальными, независимыми от конкретного оборудования. Например, большинство команд можно использовать в варианте «применить к текущей области». Например, «поставить на охрану текущую область», «включить все выходы типа сирена в текущей области», и так далее. Более того, переменные, которыми можно оперировать в скрипте, также свои для каждой области. Поэтому, если скрипт в одной области (в одной комнате) решит, что надо добавить отопления «на два деления», то в другой области (в другой комнате) этот же скрипт может решить «убавить на 5 делений». Таким образом, один, тщательно отлаженный скрипт будет работать во всех областях, не придется его копировать много раз, рискуя ошибиться при ручном вводе, или рискуя забыть, что-то исправить при многократном повторении “copy/paste”, как нередко случается.

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

Благодаря областям легко расширять систему с минимальным перепрограммированием. Если громкость системы оповещения в каких-то местах здания недостаточна, потребуется лишь установить несколько дополнительных адресных сирен, и включить их в ту же область, пометив как «пожарные». Не нужно настраивать точные связи всех извещателей, правило 2 из 3-х или 3 из 4-х, да хотя бы и времена автоотключения сирен – на новые сирены автоматически будут распространяться все настройки области. Если в какой-то комнате вы решили усилить покрытие охранными датчиками, достаточно добавить несколько извещателей, включить в соответствующую область, и они сразу будут ставиться на охрану одновременно с ранее установленными, они будут учитываться, когда сняты с охраны, как датчики присутствия человека для управления кондиционированием и освещением, они будут учитываться во всех остальных алгоритмах. И все благодаря тому, что основные настройки – в «области». Отдельные устройства можно добавлять, убавлять, заменять – функционал будет продолжать работать.