Источник: Системы безопасности, 2004 год
Любой современный отечественный каталог или журнал по тематике безопасности переполнен рекламой систем, интегрирующих в себе все и вся. Попытка же познакомиться с этими системами поближе, как правило, разочаровывает - интеграция, увы, реализуется весьма половинчато. Кто-то умеет работать с оцифрованным видео, кто-то успешно подключился к импортной пожарной панели или научился работать с несколькими контроллерами системы контроля и управления доступом (СКУД). Такие системы жестко зажаты в рамках технических возможностей оборудования, под которое написано программное обеспечение (ПО) - это либо «свое» оборудование, либо импортное, зачастую со взломанными протоколами.
Несколько лучше обстоят дела у таких крупных мировых интеграторов, как, например, HONEYWELL и SIEMENS. При этом к их недостаткам следует отнести дороговизну, проблемы с технической поддержкой и локализацией ПО.
Таким образом, взяв доморощенную «интегрированную систему», мы чаще всего имеем больше поставленных проблем, чем решенных. Пользователь, как правило, это осознает уже тогда, когда потрачены средства на систему.
Имеется достаточное количество публикаций, обосновывающих те или иные системные подходы к решению задачи глобальной интеграции, но практически нет ни одной работающей системы, удовлетворяющей всем требованиям Заказчика. В настоящей статье мы попытаемся наметить пути решения данной проблемы.
Сначала попробуем сформулировать требования обобщенного Заказчика к современным системам комплексного управления инженерными подсистемами здания, включая электронные средства безопасности. Как специалисты в области безопасности, мы начнем со своих «родных» подсистем, что не означает их превалирующего положения в списке. В состав современных инженерных подсистем здания входят:
Сама же задача интеграции формулируется достаточно просто:
К сожалению, ни один российский производитель интегрированных систем не может предложить готовое к внедрению решение, охватывающее все перечисленные выше задачи. Более того, о некоторых из приведенных подсистем и задачах интеграции знают в деталях только профильные, специализирующиеся на этом компании.
Развитие информационной инфраструктуры современных зданий привело к появлению структурированных кабельных сетей - СКС. Они обеспечивают сегодня не только обмен информацией между компьютерами, но и телефонию, а также передачу сигналов управления некоторыми инженерными подсистемами.
Развитие систем автоматизации производства породило такой программно - аппаратный продукт, как «открытые»SCADA системы. Это универсальный инструмент интеграции со стандартизованными протоколами обмена данными, широкой номенклатурой периферийного оборудования, простым, настраиваемым и понятным конечному пользователю программным интерфейсом.
В России уже имеются реализованные на базе SCADA проекты управления инженерией зданий, включая некоторые функции систем безопасности. Но, к сожалению, и SCADA не панацея. Будучи мощным и удобным инструментом для систем управления производством и промышленной автоматикой, этот инструмент в силу своей конкретной ориентации сегодня практически не пригоден для реализации некоторых специализированных подсистем (например, для управления доступом или систем видеонаблюдения).
Таким образом, можно с уверенностью сказать, что законченной (готовой к немедленному употреблению) платформы для реализации глобальной интеграции пока не создано...
Есть несколько путей дальнейшего развития глобальной интеграции. Какой из них стратегически правильный - это вопрос, ответ на который может вскоре радикально изменить ситуацию на рынке интегрированных систем.
Частные решения
Есть путь, который вряд ли приведет к появлению принципиально новых интегрированных систем. Постепенно все производители систем безопасности стараются включить в свои системы все больше и больше дополнительных «интеграционных» функций, но сама основа построения таких универсальных систем ведет в тупик. Чаще всего основой таких современных интегрированных систем является развитая СКУД (объективно - наиболее интеллектуальная из всех систем безопасности). Но изначальная постановка задачи интеграции при разработке такой системы ставит целый ряд принципиальных ограничений, которые на определенном этапе развития нам представляются непреодолимыми.
Принципы подключения оборудования, структуры баз данных, алгоритмы обработки событий - все в таких системах изначально ориентируется на задачи СКУД, а некоторые дополнительные функции впоследствии наращиваются достаточно искусственно. С точки зрения универсальной интегрированной системы такие решения являются тупиковыми.
Системный подход
Реальная интегрированная система может быть построена только на основе системного подхода, который предполагает простую вещь, осознаваемую далеко не всеми разработчиками:
Во-первых, требуется разработка не конкретной системы, которая рано или поздно не даст возможности дальнейшему развитию интеграции, а инструмента для построения интегрированных систем. Пояснить это можно парой примеров.
Пример первый. SCADA - системы. Мы имеем дело с инструментом - специальной высокоуровневой прикладной средой программирования для задач автоматизации, а не прикладной программой для тех же целей.
Пример второй. Бухгалтерия 1С. Повсеместное вытеснение с рынка бухгалтерских программ других разработок связано именно с тем, что фирма 1С создала инструмент для решения разнообразных финансовых задач, и каждый пользователь имеет возможность модифицировать (сам или заказать это профессионалам) свою версию, адаптируясь практически под любые поставленные задачи.
Во-вторых, стандартизация. Несмотря на очевидную необходимость стандартизации аппаратно - программных интерфейсов, эта задача легко решается лишь в области ПО. Крайне сложно эта задача разрешима в части аппаратных интерфейсов поскольку, в отсутствии единых стандартов, разработано немыслимое количество охранных и пожарных панелей, контроллеров СКУД и другого оборудования.
Основополагающий момент стандартизации - открытость архитектуры, поскольку только такой подход дает возможность разным разработчикам решать подзадачи в рамках единых концепций. По этому направлению давно развиваются системы программирования, операционные системы, системы управления базами данных (СУБД) и т.д. И разработчикам интегрированных систем не уйти от этого, хотя и придется бороться с мощной оппозицией.
Вопросы менталитета
Такой оппозицией являются, в первую очередь, службы безопасности. Объединение в интегрированной системе электронных средств безопасности, инженерии и других подсистем вызывает сомнения в части обеспечения, прежде всего, информационной безопасности, а также в части распределения ответственности между различными службами при возникновении внештатных ситуаций.
Службы безопасности в этом наиболее упорны и консервативны, что вполне объяснимо -при простом объединении подсистем здания воедино они опасаются доступа к своим базам данных со стороны других служб.
Думается, что при грамотном проектировании интегрированной системы несложно доказать потом и на практике, что использование общего информационного пространства не ухудшает, а улучшает (именно за счет интеграции) тактико-технические характеристики системы.
При попытке увязать на системном уровне самые разные службы предприятия мы невольно приходим к вопросу о том, кто же главнее - служба эксплуатации, главный технолог, отдел кадров, служба безопасности или еще кто - то? Ни то, ни другое, ни третье. Все они являются потребителями системы. Можно взглянуть на этот вопрос с позиции анализа принципов функционирования интегрированной системы, и ответ окажется на поверхности.
Давайте посмотрим на некоторые аспекты деятельности типичного предприятия на примерах, которые для упрощения минимизированы. На рисунке 1 схематически показано взаимодействие СКУД (безопасность), систем учета рабочего времени и расчета зарплаты (бухгалтерия) и отдела кадров.
На рисунке 2 показано (далеко не в полном объеме) взаимодействие систем АСУП и АСУТП. Заметили общее в этих рисунках? - Абсолютно правильно! Это информация (о пользователях, о сырье еще о чем - либо) - база данных и среда передачи данных, то есть локальная сеть предприятия. А отсюда и получается ответ на вопрос: главный в интегрированной системе - это системный администратор, заведующий базой данных и ЛВС.
Для кого - то это покажется неожиданным, но чего же еще было ожидать информационных технологий?
Не будем вдаваться в функции администратора (это может быть и целый отдел), но еще раз подчеркнем, что в интегрированной системе современного, а тем более будущего предприятия это ключевая фигура.
А кто же сделает всю черновую работу - разработает оборудование, программное обеспечение, интерфейсы пользователя, инструменты для настройки столь сложного механизма управления предприятием? Это уже задача огромного количества компаний, занимающихся вопросами системной интеграции. То ли к сожалению, а то ли к радости можно констатировать, что работы здесь хватит на всех и надолго.
Какие же выводы можно сделать из всего нами сказанного? Выводы нам представляются таковыми:
После выработки основных концепций и стандартов появится возможность разрабатывать и производить ПО и оборудование, которое реально обеспечит комплексную интеграцию с возможностью компоновки систем оборудованием различных производителей в соответствии с их ценовыми и/или качественными характеристиками, либо в соответствии со специализацией фирмы - производителя.
