Какие из систем ИЗ могут взаимодействовать друг с другом и в чем выражается это взаимодействие?

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

• Пример первый: пожар. В отличие от пожарной станции, ИЗ называет причину пожара, а не просто констатирует его факт. «Код» пожара включает в работу один из нескольких предварительно разработанных сценариев: «поджог», «неосторожное обращение с огнем» и т.п. В первом случае оперативные мероприятия по идентификации преступника начинаются сразу, параллельно традиционным операциям по борьбе с огнем. Протоколы, в том числе видеоматериалы, анализируются и передаются правоохранительным органам с соответствующими рекомендациями. Второй случай выявляет виновника возникновения огня.
• Пример второй: экономия. В рамках моделирования здания и проектирования сценариев его будущей эксплуатации можно задавать предельные значения потребления ресурсов: системе ИЗ можно «поручить» истратить 12 000 рублей на освещение в будущем месяце, или, например, с октября «сжигать» (N) Ккал тепла на один кв. метр помещения, а с декабря увеличить эту цифру до (P) Ккал/кв.м.

Существуют два подхода к созданию систем «ИЗ». Первый – традиционный, второй – интегральный. Первый подход на сегодня типичен. Он состоит в том, что все системы (точнее, подсистемы) проектируются, а впоследствии изготавливаются отдельно друг от друга, и лишь потом интегрируются в рамках центрального диспетчерского пункта (ЦДП). Второй подход из-за отсутствия на рынке услуг так называемого «универсального интегратора систем» распространен мало.

Смысл интеграции в обоих случаях связан с целесообразностью:

1. создания единого log-файла, в который будут записываться все сбойные и аварийные события (например: сбои и сигналы тревоги от подсистем пожарной и охранной сигнализации, сигналы сбоев и отказов от насосных станций и вентиляционных камер, сигналы перегрузок в подсистемах электропитания, аварийные сигналы от лифтовой автоматики и т.д.);
2. создания общего журнала эксплуатации, в который записываются изменения параметров системы (например: температуры и влажности воздуха снаружи и внутри каждого из помещений/зон, направления ветра, расхода электроэнергии и тепла, фактов прохода тех или иных лиц через рубеж, времени включения/выключения определенных устройств и т.д.)
3. подключения ко всем процессам, происходящим на объекте, файла единого расписания, изменяемого по программе на уровне АСУ для активизации комплексов &kaquo;комфорта» и «безопасности»;
4. последующего анализа log-файлов и журналов эксплуатации при планировании будущих периодов.

В связи со всем перечисленным, ответов на ваш вопрос два:

1. При традиционном подходе подсистемы объединяются в рамках ЦДП. «Интеллектуальные системы» (контроллеры подсистем пожарно-охранной сигнализации, контроля доступа, видеонаблюдения, мониторинга ресурсов, управления энергетикой, вентиляцией, кондиционированием, отоплением и т.п.) подключаются к уровню BMS (Building Management System) по линиям RS-232, RS-485, LonTalk, EIB, и т.д. Подсистемы «видят» друг друга на уровне драйверов или программ управления.

   «Неинтеллектуальные» подсистемы не имеют выходов для обмена на уровне протоколов. Это, как правило, системы управления нижнего уровня (КИП, автоматика лифтов, автоматика электроснабжения и прочее). В этом случае уровень BMS должен быть «имплантирован» в систему на нижнем уровне в виде датчиков, сухих контактов, приводов и т.д.

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

2. При интегральном подходе специализированных подсистем в явном виде не существует. Существуют функции, сценарии и протоколы. Физически же ИЗ представляет собой единую инженерно-телекоммуникационную сеть с единой системой закладных, с универсальной системой распределения сервисов, оптимизированными централями. Поэтому в интегральном ИЗ ничего объединять не требуется: все объединено еще на фазе архитектурно-инженерного проекта. Исключениями являются лишь некоторые системы (охранно-пожарная сигнализация, системы активного пожаротушения и пр.), которые, тем не менее, включены в BMS, но по традиционным правилам. В интегральном ИЗ, разумеется, существует ЦДП, но роль его значительно шире: ЦДП в интегральном ИЗ выполняет (помимо стандартных функций – мониторинга событий типа «сбой», «тревога», наблюдения и управления процессами) еще и функцию планирования ресурсов и технического обслуживания.

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