Преимущества СКУД Castle

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

Одно из базовых, наиболее очевидных преимуществ СКУД Castle – это ее кроссплатформенность, возможность работать как под ОС Windows, так и под ОС Linux, что становится все более востребованным в последнее время, особенно если оснащаемые объекты относятся к разряду стратегических или находятся в ведомстве Министерства обороны.

Российская СКУД Castle: простота и функциональность

Если взять нашу СКУД Castle, то разобраться в работе системы может даже далеко не самый подготовленный пользователь. Благодаря тому, что система имеет user-friendly interface (по-русски — очень удобный в использовании интерфейс). Идеология и архитектура построения системы очень проста. Большинство закладок в интерфейсе, отвечающих за основную функциональность, всегда на виду, и значительная часть пользователей, как правило, оперирует исключительно ими, не уходя куда-то «вглубь».

Очень легко осуществляется и подключение оборудования — в отличие от других систем, где все бывает не столь очевидно. Многие аналоги имеют ограничение по facility-кодам карт, то есть, не введя в систему коды карт, использовать их невозможно. При этом в некоторых случаях найти в интерфейсе место для соответствующей настройки порой достаточно сложно. В Castle подобных хитростей нет: четырьмя кликами подключается контроллер, двумя заводится пользователь, нажимается кнопка «Применить» — и далее при прикладывании своей карты к считывателю пользователю открывается доступ. Затем в течение 15—20 минут можно провести обучение, к примеру, сотрудницы-операционистки. Достаточно показать ей, как создать пользователя, и ввести № карты – вот и все.

«Дело привычки», – могут сказать многие. Если научился устанавливать и вводить в эксплуатацию что-то, то и ладно. Зачем переучиваться? Но, как показывает практика, удобство старта и работы с системой значат достаточно много.

Отдельно хотелось бы остановиться на том, как в СКУД Castle решается вопрос с назначением прав пользователя. Основные или базовые права создаются непосредственно при заведении пользователя в систему. Ему разрешается проход везде и всегда, и далее его можно ограничить определенными точками доступа (куда можно/нельзя) и временем (когда можно/нельзя). Если же возникает необходимость создания каких-то специализированных прав доступа (с расширениями или, наоборот, ограничениями) в системе Castle предусмотрено дополнительно несколько уровней, являющихся более значимыми в иерархии. В какие-то точки доступа можно добавить дополнительный режим, который при назначении будет переопределять базовый. Он может действовать постоянно, по времени или по какому-либо событию. Простой пример: блокировка точки доступа путем двойного прикладывания определенной карты к считывателю. Просто — но порой необходимо. При этом уровни доступа формируются различными способами: можно добавить пользователю определенные точки доступа или отдельных пользователей в контроллер; либо просто добавить новый режим, а в него – точки доступа, людей и т. д. А, например, при групповом назначении можно выбрать 10 точек доступа и назначить их двум отделам. Все достаточно гибко, и каждый выбирает свой метод.

Еще хотелось бы остановиться более подробно на таком явлении в системах контроля доступа, как рост базы данных. Скорее даже с вытекающими из этого сложностями в эксплуатации СКУД. На Castle построены такие решения, где база данных составляет 2—4 Гбайт, и при поиске какого-либо события, достаточно далеко отстоящего по времени от текущего момента, поиск занимает не более 3—5 секунд. Мы провели подобные исследования после того, как к нам обратился бывший коллега, столкнувшийся с проблемой при использовании альтернативной СКУД. На ней при БД объемом 2,5 Гбайт вообще перестала работать система поиска. Кто-то закрывает подобные узкие места созданием дополнительных модулей, но это уже поиск решений, а не отсутствие проблемы.

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

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

О контроллерах СКУД Castle

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

Что представляет собой наш «клиент»? Это приложение, запускающее на сервере Рабочий стол, который просто транслируется тонким клиентом на определенное рабочее место. Таким образом, при работе с клиентской частью все действия происходят на сервере, и интерфейс формируется на нем же.

При заведении контроллера в систему Castle необходимо проделать только две операции. Контроллеры «по умолчанию» приходят без IP-адреса, у них есть только MAC-адрес, написанный на коробке. Имеется утилита, которая позволяет присвоить контроллеру IP-адрес и дополнительные параметры, как то: шлюз и сервер, с которым он будет «общаться». Вся процедура выполняется в 3—4 клика. Далее контроллер настраивается в интерфейсе программного обеспечения. На закладке «Оборудование» создается точка доступа, к ней приписывается IP-адрес нужного контроллера, появляется связь — и все подключено! Если необходимо скомпоновать какой-либо распределенный объект, лучше прибегнуть к функции создания папок. Последним легко присвоить удобную логику, например: 1 этаж – одна папка, 2 этаж – другая и т.д. Делается это для того, чтобы потом применять к ним групповую политику по аналогии с зонами в системе «Интеллект». Дополнительно можно вынести все входные точки доступа в отдельную папку, что позволяет быстро ввести какие-либо ограничения для группы объектов. Разумеется, допускается создание вложенных каталогов.

Принципиальный нюанс: в системе Castle две карты одному человеку назначить нельзя. Однако не запрещается присвоить карты машине и человеку. При этом, если они связаны, система будет в любом случае понимать, находится ли Иванов на работе и как он на нее попал — пришел пешком или приехал на машине. Castle знает, что раз машина на объекте, то и Иванов, соответственно, тоже. Более того, можно ввести допуск не только по двум картам (схема «машина+Иванов»), но и по трем («машина+Иванов+подтверждение охранника»).

Преимущества российской системы Castle перед зарубежными СКУД

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

Хотелось бы также отметить, что в плане формирования ПО многие зарубежные аналоги испытывают некоторую «тяжесть». Подразумевается, что в них зачастую СКУД — всего лишь часть большой глобальной системы, управляющей зданием целиком. При этом специалисты, занимающиеся настройкой СКУД, должны обладать специфическими знаниями, связанными с пониманием различных протоколов, используемых в этих системах. Это не теоретические выкладки – в нашей практике известны случаи, когда мы осуществляли замену СКУД в офисе компании, которая сама является иностранным производителем СКУД. Заказчик столкнулся с ситуацией, когда сложность настройки (уволились специалисты) и дороговизна восстановления утерянного лицензионного ключа привела к тому, что им было проще и дешевле заменить саму систему. К тому же они уже прекрасно понимали, что такое стоимость владения. Иногда расходы по замене зарубежной СКУД на Castle (не проигрывающей в функциональности) равна стоимости годового обслуживания импортной системы.

Не последнюю роль играет срок гарантийного обслуживания – на СКУД Castle он составляет 5 лет. Многие альтернативные СКУД «страдают» тем, что стоимость постгарантийного сервиса очень высока. Обслуживать такие системы, кроме всего прочего, могут лишь специалисты, имеющие, например, сертификат производителя определенного уровня.

Еще к минусам «тяжелых» импортных систем можно отнести отсутствие полноценного механизма учета рабочего времени. Ввиду того, что ресурсы разработки находятся за границей, им зачастую сложно объяснить, что нужно, и они не хотят возиться с поддержкой законодательства РФ и требуемых форм. Поэтому обычно из-за рубежа дается «коннектор» к базе данных (БД), а далее по принципу – есть 1С, что-то еще, берите из базы, что необходимо, и разбирайтесь сами. Клиент же зачастую сталкивается с тем, что ему приходится заказывать кому-либо дополнительную разработку, решающую проблему учета рабочего времени. Конечно же, мы по аналогии сталкиваемся с незнанием вопросов учета рабочего времени в других странах, но готовы выполнять все необходимые доработки.

Интеграция СКУД Castle с другими системами: биометрия, фотоидентификация и защита данных ЦОД

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

Относительно преимуществ Castle для определенных решений. У нас есть один объект, на котором заказчик изначально хотел использовать следующие идентификаторы: и радужную оболочку глаза, и фото лица, и геометрию руки, и отпечаток пальца. В процессе работы над ТЗ мы постарались привести все в вид, наиболее приближенный к реальной жизни. Например, было понятно, что одновременное применение большого количества идентификаторов просто затрудняет пользование системой. Ведь когда при проходе сотруднику требуется приложить палец, потом карту, а затем посмотреть в прибор – это выглядит как целый ритуал… В итоге в пользовании остались отпечаток пальца, карта и радужная оболочка, но на разных точках прохода и в разных комбинациях. При работе на этом объекте мы столкнулись с необходимостью доработки ряда модулей Castle и получили то, что гарантированно отсутствует в других системах.

В Castle реализована автоматическая выдача карт доступа по какому-либо признаку. Например, одним из них может быть радужная оболочка глаза. Как это выглядит? Заказчик поставил условием использование карт только на территории объекта и, соответственно, запретил их вынос за проходные. Сотрудник или постоянный посетитель объекта занесен в систему по биометрическим признакам – отпечаток пальца либо изображение радужной оболочки глаза. При входе на объект он смотрит в устройство распознавания (прикладывает палец) и получает карту из прибора автоматической выдачи. На карте указано время действия и уровень доступа. После чего человек начинает передвигаться там, где ему разрешен доступ. Карты при этом могут быть трех видов: посетителя, постоянного сотрудника и руководителя (начальника смены). Если на объекте имеются помещения, куда доступ строго ограничен, то существует алгоритм, по которому рядовому сотруднику попасть туда можно только после подтверждения прохода картой руководителя (начальника смены).

Однако если функция прохода по двум картам реализована и в других системах, то в Castle предусмотрено и нечто уникальное. Речь — о модуле интеграции с системой хранения мелких предметов. Например, стоит шкаф с ячейками. Вы подходите и прикладываете карту. Открывается любая свободная ячейка. Вы кладете в нее мобильный телефон, планшет, флэшки, документы и все, что запрещено проносить на территорию объекта. Закрываете ячейку. При выходе с объекта все, естественно, в обратном порядке: прикладываете карту, открывается ваша ячейка, все забираете и уходите. Уже работающее решение выполнено на базе Castle и системы депозитных ячеек компании «Промет», но аналогичный проект может быть совместим и с другим оборудованием.

Еще был создан продукт, который в каком-то объеме уже описан на нашем сайте — называется он Специализированный контроллер Castle R2Rack для ИТ- инфраструктуры. Это 1U-решение, которое вставляется в телекоммуникационный шкаф и защищает его. К нему подключены датчики и замки. Доступ к данному шкафу осуществляется, соответственно, только по карте. И, в отличие от единственного имеющегося сегодня на рынке решения, не представляет собой «вещь в себе», а может работать в рамках развернутой на объекте СКУД. Конечно, если эта СКУД – Castle. И мы данное решение совместно с ЛАНИТ и другими ведущими интеграторами будем продвигать на рынке охраны ЦОД.

Отметим также хорошо и удобно созданный механизм фотоидентификации. Предусмотрено уже много готовых шаблонов, формирующих экраны, как то: «Карточка пользователя», «Протокол событий»... А еще существует конструктор, который позволяет переделывать интерфейс, что называется, «под себя». В частности, можно создать в системе карту охраняемой территории, нанести на нее значки, символизирующие определенные объекты, и управлять их состоянием (блокировать/разблокировать). Например, на одном из объектов в техническом задании было требование к реализации следующей схемы: шесть проходных, и над каждой висит отдельный монитор со своей фотоидентификацией. Реализовать такой проект с помощью нашей СКУД было достаточно просто.

Другие примеры интеграции Castle

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