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

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

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

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

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

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

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

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

image

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

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

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

image

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


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

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

image
СКУД «РУБЕЖ»

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

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

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

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

image
СКУД «БОЛИД»

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Результаты


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

Аллилуйя!

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

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

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

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

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

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


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

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

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

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

Еще посты:

Комментарии (25)


  1. Ivan_IT23
    19.12.2023 13:30

    Молодцы, что похоронили эту чудище сделанную дендерно-фикальным методом.

    Интересная статья, автор пиши ещё!


  1. annakalashnikova
    19.12.2023 13:30

    "Ни в коем случае не менять направление турникетов на КПП" - вот это 100% подмечено. Тут в одном интерфейсе кнопки местами поменяли, эффект был разрушительным :-)


  1. Rekandy
    19.12.2023 13:30

    Спасибо за то что разбавил мою скучную лекцию по физике, статья мне понравилась )


  1. vantage
    19.12.2023 13:30

    C2000-Ethernet + C2000-2, по моему мнению хуже СКУД на Рубеж.
    А лучше использовать нормальные контроллеры доступа, их российского производства полно: Apollo(завялено что теперь российская), Parse, Perco, Eslsys, Castle/Sphinx, Rusguard, и пр.


    1. SmileyK
      19.12.2023 13:30

      Плюс мильон, хуже не видел ....


    1. Mimizavr
      19.12.2023 13:30

      +100500. БОЛИД это ж больше про охранную сигнализацию и пожарку, поэтому родной СКУД ставят прицепом к ним -- в такой схеме действительно и обслуживать проще и нет зоопарка производителей и встроенная интеграция. Но вот если брать и строить систему с нуля, то лучше какого-нибудь производителя именно СКУД: у них и возможностей больше и проще настройка


    1. evil_rrock
      19.12.2023 13:30

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


      1. vantage
        19.12.2023 13:30

        Странно, насколько знаю, в центральном офисе установлен Elsys


        1. evil_rrock
          19.12.2023 13:30

          Elsys не самое популярное решение на рынке слаботочных систем.


  1. maxlenin1979
    19.12.2023 13:30

    СКУД , да ещё такой большой.. Геморой.. Нет уж


    1. zaral
      19.12.2023 13:30

      Ну 600 человек не такой большой)) у нас почти 4к)) и если монтаж новой системы не был проблемой, то вот перенос базы из КОДОСа в БАСТИОН-2 оказался тем ещё геморроем)) сейчас надо в базе порядок навести и на новую версию драйверов перейти))


      1. Mimizavr
        19.12.2023 13:30

        Видел схемы СКУДов на 100-200К, разнесенные по нескольким городам. Но там уже произведение искусства с интеграцией в AD, корпоративные CRM и доступом к сети.


  1. TheHangedKing
    19.12.2023 13:30

    Интеграция с уже имеющимися пожарными системами

    Делали мы как-то раз такое на Perco. Со стороны АПС были сухие контакты, со стороны контроллера Perco - мокрые. Всё было просто, поскольку СКУД поддерживал встроенные скрипты, которые можно было вешать на разные события, в нашем случае на замыкание мокрых контактов контроллера.


    1. evil_rrock
      19.12.2023 13:30

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


      1. TheHangedKing
        19.12.2023 13:30

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


        1. evil_rrock
          19.12.2023 13:30

          В реальном мире надёжнее всего физический разрыв питания замка. Моделируем ситуацию. Пожар, всё полыхает. Ваша сотня контроллеров в пожаре начинает вести себя чудесно. Какой-то контроллер сплавился и перестал отдавать сигнал дальше. Контроллеры не разблокируют двери, люди горят. Не лучший вариант. Теперь моделируем ситуацию с системой апс болид и с участием релейного модуля С2000-СП1. Цепь питания замка проходит через реле, которое после сработки пожарной тревоги отключается и замки разблокируются в любом случае, так как с реле уходит питание и оно перестаёт пропускать ток на замок. Люди целы, никто не сгорел, никто не сел в тюрьму. =)


  1. ovn83
    19.12.2023 13:30

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


    1. evil_rrock
      19.12.2023 13:30

      Болидовский Орион то ещё УГ


  1. azomorth
    19.12.2023 13:30

    А почему не пошли дальше и не сделали проход по биометрии?
    Ведь кучу всего меняли.

    з.ы за статью спасибо, прочитал с удовольствием.


    1. kurnvs Автор
      19.12.2023 13:30

      Тему биометрии даже и не рассматривали, честно говоря. Нет такой потребности. Конечно есть понимание, что использование биометрии более надёжно и не допускает таких ситуаций, как с картами доступа. Например, передача карты доступа коллеге для отметки в системе учёта рабочего времени. К слову, такая ситуация пару раз случалась (явление крайне редкое) и охраной пресекалась. И на этот случай вполне хватает функционала ПО Фотоидентификации на посту охраны и системы видеонаблюдения.

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

      В общем, это пока для нас неактуально, как руководство посчитает нужным внедрять — сделаем.


      1. TheHangedKing
        19.12.2023 13:30

        Когда у нас сотрудники стали копировать карты и открывать двери брелоками, волевым решение учредителей мы перешли с EM-Marine на Mifare с шифрованием.


    1. KN_Dima
      19.12.2023 13:30

      Потому, что ЕБС


    1. Enkilde
      19.12.2023 13:30

      Сейчас про биометрию можно забыть навсегда.

      Спасибо ебс и штрафам. Охотно верю в простоту интеграции. Но платить за кбс или тем более за доступ к общей базе не будут люди.

      Сделали просто дополнительную кормушку.


  1. strvv
    19.12.2023 13:30

    прочитал с удовольствием.

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

    как все отметили - самое проблемное во всех работах безопасности, и не только, человеческий фактор.

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


  1. zuek
    19.12.2023 13:30

    Оооо! Вижу за автором начало знакомства с многообразием способов взаимодействия со СКУДами. Из личного - виденные мной "Болиды" работали с картами EM-Marine, и хранят шестнадцатеричное представление номера карточек, другие системы могут их хранить как в виде "длинного целого", так и в виде "разделённого точкой" - все форматы замечательно конвертируются друг в друга (хоть на тетрадном листике, хоть простейшим скриптом). Упомянутый "расчёт компенсации питания" колхозил трижды, разными способами - от установки на раздаче столовой ПК (с ридером), отображающим данные желающего пообедать, интерфейсом 1С, до полностью самописной проги, дёргающей USB-релюшку, открывающую турникет на входе в столовую (прога тащила пропуска из БД "Парсека", "Болида" и текстового файлика, выгружаемого из аналога описанного в статье "Рубежа"), либо вообще, установкой Болидовского контроллера на кассе - если "проход разрешён", пробивается "бесплатный обед", если "проход запрещён" - идёт платное обслуживание (в том случае столовая находилась за территорией завода, и обслуживала всех желающих; данные в Болид импортировались из 1С:ЗУП, где в зависимости от графика смен, сотрудникам назначались "смены питания"). Во всех случаях на мне лежала как минимум интеграция разрозненных баз; обычно "модуль обмена" колхозил на PHP, иногда даже с вэб-интерфейсом... давно, правда, это было - думаю, с тех пор появились куда более продуманные и завершённые решения - например, последний проект, с которым я пересекался - пришлось загружать в какую-то надстройку над Р-Кипер активные пропуска под видом "абонементов"... благо, с тех пор отдалился от СКУДов и заводских столовых =)