Контакты
Подписка
МЕНЮ
Контакты
Подписка

Лекция первая. Сетевые системы контроля и управления доступом, или Сквозь смех и слезы

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Лекция перваяСетевые системы контроля и управления доступом, или Сквозь смех и слезы

Все мы по жизни критики. С тщательностью вдумчивого пса мы обнюхиваем любую статью, выражая свое несогласие любым доступным нам способом. Но спорить с уже написанным – как после драки кулаками махать. А вот будь это, скажем, лекция – то тут дело другое, тут и помахать можно. Поэтому, читатель, представь себе небольшой зал, тихую, вдумчивую, местами дремлющую аудиторию, вредного оппонента на первом ряду и вашего покорного слугу на сцене. Представили? Ну так вперед…
Аркадий Гамбург
Генеральный директор OOO "Семь печатей"

Докладчик: Тема нашей сегодняшней лекции для специалистов в области обеспечения безопасности – сетевые системы контроля и управления доступом. И хотя все вы, господа, прекрасно знаете, что такое сетевые СКУД, я, с вашего позволения, вначале попробую дать определение предмета нашего разговора.

Само словосочетание "сетевые СКУД" уже имеет минимум два значения…

Оппонент: Минуточку, минуточку. Может вы, батенька, сначала скажете нам, что такое эта ваша СКУД?

Д. (растерянно): Так это и так все знают.

О.: А я вот не знаю.

Д.: Ну, хорошо… СКУД – это аббревиатура: системы контроля и управления доступом, то есть совокупности средств, позволяющих, во-первых, идентифицировать человека, во-вторых, принять решение о праве его прохода на определенную территорию и, в-третьих, реализовать это право посредством открытия преграждающих устройств.

О.: Да под это ваше определение подходит любой вахтер…

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

Так вот, термин "сетевые СКУД" может означать…

О.: Прошу прощения, а существуют только сетевые СКУД или еще какие?

Д.: Какие?

О.: Ну же: сетевые и…

Д . (неуверенно): Не сетевые?

О. (издевательски): Умничка… А можно поподробнее?

Д. (пожимая плечами): Собственно, несетевые СКУД – это отдельные автономные контроллеры, как правило, однодверные. Яркий пример таких СКУД – устройство входа в ваш подъезд с помощью "таблеток", говоря по-научному, ключей Touch Memory. Как правило, эти контроллеры очень просты, дешевы, их функциональность сводится исключительно к проверке кода, они не имеют никаких внешних интерфейсов и не могут использоваться для построения именно СКУД как системы. В отличие, кстати говоря, от большинства истинно сетевых контроллеров, которые прекрасно могут работать и в автономном режиме.

О.: Ну вообще-то, коллега, если вы зайдете на сайт любой компании по безопасности, то найдете там разделы "Сетевые СКУД" и "Автономные СКУД".

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

О. (вскакивая и с пафосом): Есть такие системы! Я думаю, любой в этом зале понимает, что такое современная электроника. Сейчас на рынке появляются, как вы пренебрежительно выразились, очень простые, очень дешевые, но при этом весьма и весьма функциональные устройства, которые иначе как высокоинтеллектуальной, хоть и автономной, системой доступа и не назовешь…

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

Крики из зала: Хватит! Да дайте же докладчику говорить! Нам это неинтересно!

О. (примирительно вскидывает руки): Молчу, молчу.

Д. (миролюбиво): А вы, коллега, говорите интересные вещи, в следующий раз мы вас с удовольствием послушаем.

О. (картинно кланяется): Всегда к вашим услугам!

Д.: Так вот, господа, я возвращаюсь, наконец, к теме своего доклада (опасливо смотрит на оппонента, но тот скучающе молчит). Понятие "сетевые СКУД" означает, что бы ни говорил мой уважаемый оппонент, прежде всего именно систему, то есть наличие нескольких (более одного) контроллеров, объединенных в сеть и подключенных (или связанных) к единому управляющему центру. Как они объединены и как связаны, нам пока не важно. Главное здесь то, что в этом случае контроллеры становятся не более чем исполнительными механизмами, ретранслирующими события от внешних устройств в центр управления и принимающими от этого центра команды. Как правило – команды включить реле.

О. (тянет руку, как школьник на уроке): Можно вопрос?

Д. (настороженно): Да-да…

О.: Одна песчинка – это куча?

Д.: Что, простите?

О.: А две? А три? Когда начинается куча, то есть, простите, сетевая СКУД? Задам вопрос иначе: может ли сетевая СКУД состоять из одного контроллера?

Д. (чуть краснея): Конечно, если это сетевой контроллер.

О.: Так, значит, для создания сетевой СКУД нужны не просто контроллеры, но некие сетевые контроллеры?

Д. (раздраженно): Ну уж, конечно, не ваши автономные.

О.: Так вы про это не сказали.

Крики из зала: Довольно! К делу!

Д. (успокаиваясь): Для построения сетевой СКУД должны и могут использоваться только сетевые контроллеры доступа, то есть имеющие соответствующий интерфейс для подключения внешних линий связи. Понятно? (Выжидающе смотритнаоппонента.)

О.: Теперь да.

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

Прошу вас, маэстро, первый слайд!

(Маэстро-помощник артистично проходится по клавиатуре, и наэкране появляется первый слайд.)


Итак, с чего начинается сетевая СКУД? Может, как выразился мой оппонент, с железной коробки? А может, с этих ветвистых линий связи? А может, она начинается с мудрого управляющего центра? Нет, нет и нет. Как театр с вешалки, так и СКУД начинается с периферийных устройств. Это прежде всего считыватели совершенно разных типов, форм, расцветок и принципов действия. Это датчики двери и кнопка открытия. Это реле, которые служат для включения любых исполнительных устройств...

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

Следующий элемент сетевой СКУД – непосредственно сам сетевой контроллер. Назначение контроллера – считывать данные с периферийных устройств, передавать их в управляющий центр или центр принятия решений, о котором речь впереди, и выполнять решения центра, то есть включать реле.

Однако здесь есть одна важная особенность.

Мы уже говорили, что в сетевой СКУД решение принимает центр, а контроллер только послушно следует ему. Однако любой военный человек скажет вам, что связь с центром в любой момент может оборваться, и тогда решения должен принимать непосредственно командир на поле, так сказать, боя. На передовой. А для контроллера передовая – это обслуживаемые им двери. Одна, две, ну или там восемь. Не принимать решения нельзя, иначе через дверь – или турникет – никто не пройдет, и она сам станет полем боя: нетерпеливый народ начнет ломать замки и гнуть рога турникетов…

Поэтому контроллер при таком форcмажоре должен брать управление на себя. Отметим это и пойдем дальше…

О.: Вот! При таком мажоре контроллер и становится автономным!

Д.: Ну да, конечно.

О.: Так вы пять минут назад вообще отказывались их рассматривать.

Д. (холодно): Все надо делать вовремя. Я должен был говорить об автономном режиме здесь и сейчас. А вы втянули мне в бессмысленную, как русский бунт, дискуссию и уже поведали аудитории все об этом предмете. Поэтому – дальше.

Дальше и начинается непосредственно сетевой уровень системы – связь с управляющим центром. Способов связи на сегодняшний день всего два.

Первый – по специально проложенной, выделенной линии связи, или, как ее еще называют, межконтроллерной линии.

Второй – использование локальной сети, то есть с подключением контроллеров непосредственно в Ethernet-розетки, передачей данных по ЛВС и приемом их управляющим центром по соответствующим IP-адресам.

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

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

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

О.: Ну, вы, батенька, и ретроград!

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

О.: По-моему, вы застряли где-то в прошлом веке на уровне коаксиальных сетей в досе. Да пользуйтесь нормальными сертифицированными средствами защиты, паролями, доменной политикой, антивирусными программами, никто и никогда вас не тронет. Нельзя же так огульно отрицать прогресс вообще. Зачем заставлять заказчика тянуть километры дополнительных кабелей… разве что денег с него слупить…

Шум в зале, крики: Долой! А он прав! Не мешайте.

Д. (примирительно): Хорошо, коллега, я частично согласен с вашими доводами. В принципе выбор способа организации сетевой СКУД – прерогатива заказчика, как он скажет, так и будет. Если заказчик ставит во главу угла безопасность и надежность – мы рекомендуем ему прокладывать выделенную линию, если экономические соображения и сроки монтажа системы – то разумно ему не перечить и, не мудрствуя лукаво, быстренько повтыкать контроллеры в RJ-45. Благо, что пока почти все производители оснащают свои контроллеры как 422-м интерфейсом, так и Ethernet. Такая формулировка вас устроит?

О.: Более или менее…

Д.: Тогда настало время перейти ко второй характеристике сетевых СКУД, а именно к типу центра управления, к тому, кто, собственно, и как управляет системой.

Как видно из второго слайда, существует два вида центра управления. Первый – контроллер, второй – компьютер…

(Оживление в зале.)


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

Понятно, что системой из соединенных проводами блоков управления дверями надо управлять. Лучше всего, скажет вам сейчас любой школьник, завести все эти провода на компьютер, написать программу, создать базу данных – и вперед, ноу проблем… Но на заре становления СКУД компьютеры были слабыми, ненадежными, дорогими, да и были далеко не везде. А вот электронные микросхемы с процессором и памятью вполне достаточных для программирования простеньких алгоритмов на ассемблере уже имелись, был и опыт разработок подобных устройств для промышленности и – в гораздо большей степени – для оборонки. Поэтому вполне логично, что отечественные разработчики в основном пошли по пути несколько опередивших их западных коллег и стали строить сетевые системы на управляющих контроллерах.

В результате получалась двухуровневая структура: дверные контроллеры – управляющий контроллер. Чаще дверные контроллеры назывались платами расширения, а управляющие – просто контроллерами.

Казалось бы, задача решена, построил такую систему, занес ключи, задал права доступа – и вперед, как говорится, и с песней, и без всяких компьютеров…

Но – дьявол в деталях. Первая деталь с маленьким дьяволом: как заносить ключи? Я знаю только один способ – с мастер-картой. Это удобно. Для 10 карт, ну для 100, но когда речь идет о тысячах, да еще в десятки контроллеров, то… Дьявол номер два – у каждого ключа есть свои собственные права и, естественно, обязанности. Например, право проходить через проходную и обязанность делать это в восемь утра и в пять вечера. И как, скажите, с помощью мастер-карты объяснить это контроллеру? Третий дьявол, как Кощей над златом, чахнет над памятью о событиях: кто когда куда ходил. Как получить эти данные из железного ящика для, к примеру, составления отчета о нарушениях?

Вам уже понятно, что без связи сети контроллеров с компьютером наша сетевая СКУД никому на этом свете не нужна, а на том – тем более.

Маэстро, третий слайд.


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

И только теперь мы можем сказать, что получили истинно сетевую СКУД.

В данной схеме мы ввели третий элемент – компьютер. И уже ответили на вопрос "Зачем?": для настройки системы прав, занесения ключей и считывания событий, причем желательно в реальном времени, то есть сразу. Еще раз подчеркну – само управление системой осуществляется на уровне контроллеров.

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

Чем хороша такая схема? Прежде всего – надежностью. Все необходимые для непосредственной работы СКУД данные хранятся в контроллерах, вся информация от оконечных устройств через платы расширения передается на контроллеры, все решения принимаются теми же контроллерами. Есть ли компьютер, нет ли компьютера – для контроллеров неважно.

Чем эта схема плоха? Опять-таки надежностью.

О.: Чем это надежность плоха?

Д.: Тем, что подводит. Это как надежный друг, на которого полагаешься как на самого себя и даже больше, знаешь, что он никогда не подведет… А он вдруг подводит… Мол извини, друг, не смог, ну не смог, ну никак… И здесь то же: вы уверены, что система на уровне "контроллер – платы расширения" работает всегда, а тут – бац! – и связь контроллера со своей платой обрывается. Может, крысы ее перегрызли, может, монтер Вася маханул бокорезами. И что будет с нашей надежной системой? Плата расширения – или дверной контроллер – не будет открывать дверь, потому что им никто не командует, а сам он, как боевая единица, думать не обучен и что делать – не знает. Вот и вся надежность.

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

Д.: Сейчас – да, но 5–10 лет назад не помнил.

Но есть еще более узкое место в этой схеме. Представление об объекте в целом. Я говорю о глобальных режимах, для которых необходимо знание обо всех событиях, происходящих в системе, где бы они ни имели место, так сказать, от Москвы до самых до окраин… Яркий пример тому – Antipassback. Как нельзя дважды войти в одну и ту же реку, так и нельзя повторно зайти на территорию, если ты не вышел с нее. Подчеркиваю – где бы ни зашел и где бы ни вышел.

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

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

Д.: Не передергивайте. Я не ругаю, я честно показываю как достоинства, так и недостатки.

О.: У каждого есть свои недостатки…

Д.: Несомненно. Описанная схема настолько широко распространена, что было бы глупо отрицать ее жизнеспособность только по причине возможных коллизий. В конце концов, на крупных объектах все системы безопасности обязательно дублируются службой безопасности, которая в случае чего будет старым проверенным способом "пущать" или "не пущать", потому что, как мы уже отмечали, самая надежная СКУД – это вахтер.

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

Маэстро, пожалуйста, слайд номер четыре.


Вот, господа, и второй вариант. Управление всей системой исходит из одного центра, от абсолютного, так сказать, компьютерного монарха. Ну, или монархического компьютера. Или, как это называется на современный манер, сервера СКУД.

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

Но как гласит известный закон, все, что может сломаться, – ломается. А что сломаться не может – ломается тоже. Поэтому при обрыве связи с центром все контроллеры системы обязаны работать автономно…

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

Д.: Товарищ не понимает. Придется сделать официальное заявление.

Я и раньше утверждал и сейчас утверждаю, что при любой схеме построения сетевой СКУД контроллеры должны уметь автономно управлять исполнительными устройствами, то есть выполнять необходимый минимум анализа "кого пускать – куда пускать – когда пускать". Без этого джентльменского набора СКУД просто не имеет права на существование.

И первое, что надлежит сделать, сдавая систему заказчику, – выключить сервер и показать: смотри, система работает, она пускает людей по заданным правилам. Не отображает – да, не грузит новые карты – да, не создает отчеты – да. Но пускает всех, кого положено, и не пускает остальных. И как только я включу сервер – вот смотри, включаю, – сразу начнут отображаться события, грузиться ключи, скачиваться события и формироваться отчеты.

Это катехизис любого честного эскадешника – от разработчика до монтажника.

Я могу продолжать?

Итак, мы обозначили две основные схемы построения СКУД. Теперь у нас есть что с чем сравнивать, и сравнивать мы будем на примере объекта особо крупного размера.

Маэстро, дайте нам, пожалуйста, пятый и шестой слайды.


Именно на такой системе отчетливо видны особенности обоих решений.

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


О.: Чей смех и чьи слезы?

Д.: Смех, видимо, инсталляторов, ну а слезы, слезы, конечно, пользователей…

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

Причем вы помните, что сама по себе она двухуровневая: платы расширения или дверные контроллеры, непосредственно контактирующие с внешней "дверной" средой – считывателями, герконами, кнопками, замками, турникетами и прочим – и управляющие блоки или контроллеры, не марающие, образно говоря, руки о внешние устройства, а выполняющие аналитическую работу по обработке информации и принятию решений о допуске.

Другой своей стороной управляющие контроллеры связываются с компьютером, с этаким маленьким Росстатом, перед которым они обязаны отчитываться о проделанной работе – кого пустили, когда и куда, а если не пустили, то почему, собственно. И все – никакого влияния извне, ну разве что новые ключи погрузить в память да права доступа урегулировать.

Вроде все хорошо, логично, понятно и надежно. До тех пор, пока эта двухуровневая структура остается двухуровневой. То есть, как мы уже говорили, не появляется еще одна гроздь "контроллер – блоки расширения".

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

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

Непривлечение же чревато сложной – особенно для объектов с сотнями контроллеров – системой обмена данными "каждый с каждым". Сложной даже при наличии постоянной связи между контроллерами.


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

Хорошо это или плохо?

С точки зрения надежности, конечно, плохо. Линия связи с контроллерами, компьютерное "железо", операционная система, далеко не идеальное и достаточно сложное программное обеспечение СКУД – все это резко увеличивает вероятность сбоев в системе.

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

О.: Позвольте, позвольте, как это любые? Вот скажите, сколько вы можете завести контроллеров даже по вашему любимому выделенному 422-му интерфейсу на сервер?

Д.: Ну, во-первых…

О.: Причем все здесь присутствующие должны понимать, что под 422-м или 485-м понимается старый добрый СОМ-порт, устаревший, как трамвай…

Д.: Все присутствующие должны знать, что на сегодняшний день СОМ-порт – самый надежный коммуникационный вход на компьютере, все разработчики снабжают им свои устройства, а некоторые – только им, игнорируя ваши любимые USB-порты и IP-соединения.

О. (морщится): И опять вы отрицаете прогресс. Где на современном компе СОМ-порт? Я уже не говорю о планшетниках и смартфонах…

Д.: А вы контроллеры что – к мобильнику хотите подключить?

О.: А почему бы и нет? По большому счету эра компьютеров кончилась, как эра динозавров. Да само слово "компьютер" уже неприлично произносить…

Д.: Вы… да вы… да вы просто фантаст какой-то, причем даже не сайенс, а самый натуральный фикшн.

Крики из зала: Хватит! Не мешайте! Давайте кончать! Караул устал!

О.: Хорошо-хорошо, молчу. Вы все же на мой вопрос, пожалуйста, ответьте.

Д.: Про динозавров?

О.: Про число контроллеров на нитке.

Д. (пожимает плечами): Так это только барон Мюнхгаузен мог нанизывать на нитку столько уток, сколько было на озере. Да и то потом дотащить их не смог. Во всем нужна мера.

О.: Барона утки сами донесли до дома, а вот вы, батенька, все время уходите от ответа.

Д.: Да нет ответа на ваш вопрос, барон, то есть, простите, коллега. Есть хорошее английское выражение It depends. Это зависит от многого: числа портов на контроллерах, интенсивности проходов на этих портах, мощности сервера, функциональности системы…

О.: Ну все же, все же, не сотни же…

Д.: Нет, конечно. Реально – два-три десятка.

О.: Во-от! Где же ваши любые размеры?!

Д. (с сожалением смотрит на него и стучит себя пальцем по виску): Вот здесь, коллега. Я недаром сначала сказал о любой топологии. Все понимают, что скорость обмена по 422-му протоколу ограничена сама по себе, ограничена скорость порта, ограничены производительность компьютера и скорость программной обработки событий. Кроме того, вешать все контроллеры СКУД на одну линию – примерно то же, что складывать все яйца в одно лукошко. К тому же это невыгодно и экономически: тянуть длинный-длинный кабель по всей территории. И еще, и еще, и еще…

Так что серьезные системы никто по Мюнхгаузену не строит. Даже на моем слайде хорошо заметно, как контроллеры соединяются с управляющим сервером. На СОМ- или USB-порты, причем заметьте, одновременно на несколько. Через любимую вами локальную сеть. Через рабочие станции сети. Неужели мало способов может придумать умный человек?

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

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

О. (ехидно): И финансирование…

Д.: Что же, за все надо платить…

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

Подведем итог.

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

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

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

Благодарю всех за внимание, моего уважаемого оппонента – за посильную помощь.

Вопросы прошу присылать в письменном виде.

И до новых встреч в нашем лектории.

Опубликовано: Каталог "СКУД. Антитерроризм"-2014
Посещений: 9251

  Автор

 

Гамбург Аркадий Ефимович

Генеральный директор
ООО "Семь Печатей"

Всего статей:  16

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций