8 (800) 222-42-27
Подписаться
на новости и события
Расписание
Февраль 2020
Пн Вт Ср Чт Пт Сб Вс
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1
выставка
информационный семинар
обучающий семинар

Integratio sapiens-4.

апрель 2005

Варианты комплектации интегрированных систем безопасности

На сегодняшний день существует два полярных мнения по вопросу интеграции систем.

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

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

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

Интеграционные идеализации

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

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

Однако не стоит идеализировать интеграцию. Многолетний опыт показывает, что каждая из подсистем, входящих в интегрированную систему безопасности (ИСБ) объекта, должна иметь возможность автономной работы с сохранением всех базовых функций, если что-то случилось с межсистемными каналами коммуникации. Грубо говоря, если поврежден кабель или «завис» центральный компьютер, система должна функционировать, накапливать данные хотя бы минимальный промежуток времени, необходимый для проведения ремонтных работ. Чтобы после устранения неполадок никакие данные и тревожные сигналы не были потеряны.

Можно также отметить еще одну крайность, когда заказчик стремится свести все подсистемы в средней или даже крупной ИСБ на один центр управления.

Уравнение эффективности

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

Разумеется, оператор системы контроля доступа может иметь возможность посмотреть показания системы теленаблюдения, но это не будет являться его основной функцией.

Допустим, пришел сигнал о несанкционированном вскрытии двери. Оператор СКУД может вывести у себя на экране изображение соответствующей камеры.

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

Проще говоря, не надо все мешать в кучу, это очень вредит работе интегрированной системы.

Интеграция по наследству

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

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

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

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

Некоторые компании идут на изготовление так называемого «шлюза» в программном комплексе, который позволяет инсталляторам самостоятельно написать нужный драйвер для осуществления какой-то более мелкой интеграции на конкретном объекте. Это один из вариантов решения проблемы, поскольку крупной фирме не всегда интересно и выгодно писать драйвер под какую-то эксклюзивную «железяку», который будет использован 2-3 раза. Такое решение позволяет сторонним фирмам добавлять какие-то свои системные модули.

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

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

В последнем случае задача написания драйвера под «старое железо» ложится на самого заказчика или на компанию интегратора.

Если вы заказываете ИСБ у западных производителей, то все, что стояло на объекте до этого, вам придется демонтировать и выбросить. Ни одна иностранная фирма не согласится что-либо «дописывать» в ПО, потому что им это невыгодно (конечно, если вы не владелец компании типа «Газпром»).

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

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

Отдельная тема – крупные серьезные объекты. Там в большинстве случаев необходима глубокая интеграция.

Интеграция технологий

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

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

У многих производителей «базовых» систем безопасности, например, СКУД и ОПС, интеграция уже изначально присутствует в аппаратной составляющей, то есть на уровне «железа». Это обусловлено логикой работы двух систем. Например, последний человек, покидающий помещение, может поставить его на охрану, используя локальный пульт или позвонив в центральную диспетчерскую службы безопасности. В то же время интегрированная система СКУД+ОПС может автоматически поставить помещение на охрану после последнего вышедшего, так как знает, сколько человек было в помещении. Использование в ИСБ подсистем одного производителя является более предпочтительным, поскольку глубокая аппаратная интеграция более надежна, чем программная.

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



Просмотреть файл 1459.87 Кб

Полный список публикаций