Кипучий СКУД

Один из коммутационных узлов старого СКУДа. Скрутки и спайки эффектно маскировали в корпусах от радиоприёмников.

Когда я только устроился на эту территорию, я немного обалдел. У нас на щёлковской заводской площадке впервые установили систему контроля и управления доступом (СКУД) в 2008 году.

Доступ на площадь 12 гектаров обеспечивала система с грозным названием «РУБЕЖ». Для подключения её блоков между собой использовались медные многопарные кабели для телефонии, 1980–1990-х годов предположительно.

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

Технической документации до нас не дошло, а максимальный срок службы, отмеренный производителями системе «РУБЕЖ», был превышен лет так на пять.

Разобраться, что куда идёт и что к чему подключено, было очень сложно, 90% записей не совпадало с действительностью.

Однажды, например, электрики проводили плановые работы на складе и в этой зоне временно отключили электричество. Я очень удивился, когда считыватели погасли — а магниты продолжали держать дверь! Оказалось, что магниты на дверях склада были подключены к третьему этажу соседнего здания. И такие схемы подключения были повсеместно. Непонятен был принцип, как всё это реализовывалось.

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



Выглядела система грозно, ведь в этих кабелях для телефонии — от 20 до 200 жил. Со временем часть кабелей повредилась, часть и вовсе демонтировали. Тут ведь как: изменилась погода — пошли сбои, прошёл ливень — затопило кабельную канализацию, часть точек доступа вообще отвалилась. А в блоках управления точками доступа нет памяти, которая позволила бы продолжить работу без связи с серверной частью и центральным процессорным блоком. Случаи обрыва связи между блоками системы и серверной частью СКУДа стали неуправляемыми.

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

Естественно, мы среагировали, эту дверь разблокировали. Безопасность страдала из-за того, что человек на КПП не знал, кто зашёл? Куда зашёл? Также не фиксировались никакие события. У нас ЧОП из-за этого очень сильно нервничал.

Итак, почему решили менять СКУД

Первая причина — кабельная инфраструктура. Вторая причина — автономность, вернее, её отсутствие. Третья причина — схема подключения. Было много и других причин: некорректная работа базы данных, ряд программных ограничений в настройке и эксплуатации системы, нецелесообразность модернизации текущей системы и т.д. Оборудованы были не все двери, а там, где были оборудованы, — создавались очереди.

Архитектура старой системы (верхнеуровнево)


СКУД «РУБЕЖ»

Между зданиями встречалось от 2 до 7 дополнительных кросс-панелей, где всё запутывалось ещё больше! Тестер был бессилен, звонилка (тональный генератор) бесполезна — там либо всё фонит страшно, либо генерируемый сигнал гудит по десяткам линий.


Мозги старого СКУДа

Мы просчитывали разные варианты. В итоге всё сводилось к тому, что проще уже СКУД поменять. Снести всё это, забыть и поставить новое. В голове крутилось два варианта — «РУБЕЖ», с которым мы уже знакомы, и «БОЛИД». С учётом внутренней кухни по выбору поставщика победу одержал «БОЛИД».

Архитектура новой системы (верхнеуровнево)


СКУД «БОЛИД»


Коммутационный узел СКУДа «БОЛИД»

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

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

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

Нужно будет закрыть следующее здание? Это будет дело буквально на несколько дней. Здания закрываются быстро, легко, недорого.

Таким образом, мы закрыли критически важные объекты, обеспечили учёт рабочего времени и сохранность продукции.

Как в реальности прошла установка и эксплуатация СКУДа?

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

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

Начальник объекта охраны на нашей территории поставил условие: произвести максимально бесшовный переход на новое оборудование. Хотя бы на месте КПП, чтобы не рушить пропускной режим. Из серии «отключайте на здоровье, но чтобы всё работало». Для этого мы КПП решили переключать в самую последнюю очередь.

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

Ни мне, ни помогающей нам подрядной организации не удалось выгрузить из базы в нужном виде нужные сведения для экспорта в информационную систему «БОЛИД». Если честно, вообще ничего не удалось выгрузить. Система просто не работала. Поэтому пришлось переносить всё вручную.

Тут мы столкнулись с ещё одной проблемой. Идентификаторы карт доступа в системе «РУБЕЖ» и в системе «БОЛИД» распознаются по-разному. Новая система, если вписывать код карточки, который прописан в «РУБЕЖе», в «БОЛИД», его просто не примет. В какой-то момент я прям немножко руки опустил. Думал, что сейчас придётся со всех 600 сотрудников собирать карточки и вручную каждую настольным считывателем пропикивать. Я не совсем даже понимал, как это реализовать, как со всех эти карты собирать. Тем не менее параллельно обратились тоже в поддержку системы «БОЛИД». Они любезно предоставили прекрасную утилитку, которая эти коды переделывает в нужный вид.

Тем не менее всё равно это много времени заняло. Буквально два дня сидел невылазно за компьютером и все эти коды перекодировал, всё это добавлял. Переносил фамилии, подразделения, должности, коды карточек. Думал, что глаза вывалятся из-за этого.

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

Какие доработки стали нужны за время эксплуатации?

Пара доработок, которые потребовались перед началом замены СКУДа:

• Сеть. Мы с коллегами заблаговременно подготовили нашу сеть для подключения новых Ethernet-контроллеров СКУДа и АРМов, а именно выделили отдельную подсеть, отдельный VLAN, выделили IP-адреса и настроили определённые порты на коммутаторах.
• Двери. Потребовалось поменять много дверей! Правда, я бы поменял и те двери, которые уже поменяли! Поставили лёгкие, слабенькие. У особо сильных сотрудников скорее дверь или ручка в руках останется, чем они сорвут её с магнита. У нас две крайности: либо огромная и тяжеленная дверь как в бомбоубежище, способная пережить прямой ракетный удар, либо самая простенькая, которая от лёгкого прикосновения деформируется, будто самосвалом переехало.

Многие, наверное, слышали или знают, как отечественные производители пишут очень «понятные» и «доступные» инструкции? Здесь не исключение. Прочитаны тысяча страниц инструкций, огромное количество постов на тематических форумах. Тут главное понять их логику, и мне казалось, что я понял. Ровно до тех пор, пока случайно чуть не парализовал работу площадки, благо, ненадолго!

Однажды я решил перенастроить все блоки управления точками доступа в части отображения информации о том, фактически открыта ли дверь или закрыта и случаях её взлома, кроме проходной и шлагбаума. Специально выбрал поздний вечер, чтобы никому не мешать и спокойно всё проверить. Ну как проверить, наблюдать, как охрана выполняет очередной обход и проверяет за меня, сами того не подозревая, — никаких проблем, все двери работают, всё открывается и закрывается, нужная информация также отображается в логах событий. Со спокойной душой ложусь спать. Где-то в 6 часу просыпаюсь от бесконечно вибрирующего телефона — звонили все: начальник объекта охраны, старший смены, дежурные охранники, даже некоторые пользователи.

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

Все! Абсолютно все точки доступа их никуда не пускали и не выпускали. Работали лишь те карты доступа, у которых уровень доступа максимальный, а это только охрана! Включив компьютер, подключившись к серверу, я разблокировал все двери на свободный проход и начал разбираться.

Оказалось, что после моих манипуляций требовалось нажать ещё одну несчастную кнопочку «Считать конфигурацию с приборов».

Да, об этом было написано в инструкции, но не в этом же абзаце, не на этой же странице, не в этом же разделе, даже не в этой же инструкции! Шучу, но этот момент действительно был неочевиден как в реальности, так и в инструкции.

Результаты

Наконец-то почти полностью отказались от всех медных многопарников, кросс-панелей и всех связанных с ними соединений. Телефонию перевели на IP, камеры переводим на IP, модернизируем локальную сеть, теперь и новый СКУД с новой кабельной инфраструктурой + всё та же IP-технология. В работе осталось лишь несколько традиционных телефонных линий административно-управленческой связи. Всё остальное демонтируем!

Аллилуйя!

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

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

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

Теперь имеется почти полноценное бюро пропусков — АРМ с необходимым ПО, камерой, DataCard-принтером, настольным считывателем. Осталось только укомплектовать сотрудниками!

До идеала пока далеко. По сути, мы только начали. В планах поэтапно и дальше развивать систему, например:

• Интеграция с уже имеющимися пожарными системами. Работаю над данным вопросом, планирую в 2024 году реализовать. Так как пожарные системы в зданиях устанавливались в разное время, разными подрядчиками, они никак не связаны друг с другом, работают полностью автономно. За счёт того, что у нас теперь появился сервер с необходимым лицензионным ПО, в планах объединить СКУД и АПС в единую систему. Это позволит более гибко конфигурировать эти системы, настраивать различные сценарии взаимодействия систем, станет проще обслуживать и проводить диагностику. Причём объединять их планируем в «гибридном» формате — через Ethernet-контроллеры по локальной сети, а также «сухими контактами» на наиболее значимых точках доступа (прямое кабельное соединение блока точки доступа с центральным блоком пожарной сигнализации), для более высокой отказоустойчивости.
• В воздухе витает вопрос о дооснащении СКУДа системой автоматического распознавания номеров транспорта, что въезжает и выезжает с территории. Для обычного протоколирования событий, связанных с транспортом. На данный момент всё это выполняется по старинке — журналы с ручными записями.
• Возможно, ещё подумаем над автоматическим расчётом компенсации за питание в местной столовой при помощи СКУДа (смотрим, как это реализуют на других площадках в рамках группы компаний). Также, возможно, попробуем прикрутить автоматическую передачу учётных данных сотрудников из SAP напрямую в СКУД и передачу в SAP информации по каждому сотруднику из модуля учёта рабочего времени.

Что можно посоветовать на этапе выбора?

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

Единственное, что я бы себе сказал на будущее, — ни в коем случае не менять направление турникетов на КПП. Мы его поменяли — и это прям была большая боль. Чуть ли в какой-то момент не увешали всё стрелочками, что проход, выход слева, вход справа. Хоть регулировщика поставь, но перебить человеческую привычку идти, как они ходили раньше, — это большая проблема. Я боялся, что нам эти турникеты снесут рано или поздно. Это, наверное, единственный такой момент. В остальном всё прошло хорошо. Всё, как планировали.

Почти всё, как планировали.

Cпасибо Ивану Бороденкову за помощь в подготовке этой статьи.