Адрес: 142704, г. Москва, пос. Мосрентген, Институтский проезд, д. 2

Интегрированные системы масштаба объекта

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

Какие сейчас есть системы масштаба здания?

Мне встречались 5 различных типов систем, исторически развивавшихся различными путями, практически несовместимых между собой, но развившихся до стадии, когда интеграция возможна и полезна:

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

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

3. Системы управления производством (SCADA) . Самая развитая и стандартизованная среди описываемых отраслей. Ряд стандартов серии ISO описывают и полевую шину (физический уровень) и даже уровень представления - графический язык программирования IEC-1131. К сожалению, широта предметной области не позволяет иметь специализированные для безопасности подсистемы. Кроме того, все наработки ориентированы в основном на большие и очень большие системы. Утверждать, что систему безопасности можно построить на основе SCADA - все равно что утверждать, что все эти алгоритмы можно запрограммировать на любом достаточно мощном микропроцессоре. Кто ж спорит, конечно, можно: Особенно на ассемблере:

4. Системы управления сетевым компьютерным оборудованием. Работа любой большой системы существенно зависит от работоспособности компьютеров по отдельности, сети в целом и системного программного обеспечения. Соответственно, применяется ПО централизованного управления всем этим хозяйством. Или отдельные специализированные (типа HP OpenView или СА Unicenter), или, как минимум, встроенные в операционные системы. Нередко соответствующие подсистемы встраиваются и в ПО другого назначения (и даже системы безопасности), благо все программисты хорошо знакомы с основными стандартами данной области - SNMP, DMI, ММС, при этом не требуется никакого особого дополнительного оборудования.

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

Какие функции различных подсистем следует интегрировать в единую систему?

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

Администрирование и конфигурирование подсистем


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

Дежурный оператор (единая диспетчерская)


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

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

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

Автоматизация управления


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

В отличие от отображения, эта функция требует двунаправленного канала обмена данными/командами интегрирующей системы и подсистемы. При наличии более-менее стандартных каналов обмена информацией (для систем на базе Windows - это DDE, ОРС, или вообще Active-X/Automation), автоматизация возможна на основе простейших программ на Visual Basic или IEC-1131-систем, создаваемых специально под задачу.

Особенности подсистем безопасности

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

1. Ориентация на нестандартные ситуации
В отличие от систем управления технологическим процессом или систем управления отоплением и кондиционированием, системы безопасности в идеале ничего не делают. Как и у всей службы безопасности в целом, важнейшие критерий успешной системы безопасности - отсутствие событий. Главное, чтобы система безопасности эффективно обрабатывала чрезвычайные ситуации, которые, скорее всего, никогда и не произойдут. Поэтому, в частности, эту систему очень трудно постепенно совершенствовать после пуска в эксплуатацию. Большинство ее важнейших функций никак не проявляются в нормальной повседневной жизни. Для совершенствования системы абсолютно необходимо проводить специальные учебные тревоги, позволяющие проверить функционирование персонала и системы, выявить недостатки и того и другого.

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

3. Существенно распределение прав доступа к информации
Это при управлении прокатным станом, если человек имеет удостоверение на право управлять станом, так уж имеет такое право всегда, в любую смену. А в системе безопасности человек, имеющий право разрешать доступ в какую-то дверь, обычно имеет право разрешать его только в рабочее время, причем только в одну или несколько дверей, а вовсе не в любую дверь на объекте. Конечно, не всегда это верно - требования по технике безопасности на опасных производствах могут быть даже более жесткими, чем требования охраны, но традиционно вопросы охраны решаются исходя из положения "запрещено все, что не разрешено", без демократии.

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

Заключение

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

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

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


Автор: А.М. Омельянчук
технический директор
ЗАО "Компания Безопасность"
Читайте также: