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

 

А. М. Омельянчук,

технический директор

ЗАО «Компания Безопасность»

 

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

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

Что в наличии?

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

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

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

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

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

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

Что к чему?

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

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

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

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

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

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

В чем специфика?

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

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

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

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

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

Что в итоге?

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

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

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

 

«Защита информации. Конфидент», №1, 2002