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

Что использовалось, почему не подошло и что хотел заказчик

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

Техническое задание включало следующие пункты:

Увеличить количество камер СВН для покрытия не менее 90% площади предприятия и цехов;

Расширить количество дверей, оснащенных электронными замками, а также установить дополнительные модули считывания, контроллеры, датчики открытия/закрытия и доводчики;

Установить систему контроля запретных зон;

• Заменить стандартные турникеты на двух КПП и при входе в один из цехов на полноростовые, оснащенные терминалами с функцией распознавания лиц (с целью недопущения передачи пропусков для отметки прихода на работу);

• Подключить шлагбаумы на КПП к системе распознавания автомобильных номеров с использованием защищенных 4К видеокамер для автоматизации проезда транспорта;

• Интегрировать СКУД, охранную сигнализацию, СВН, системы распознавания лиц и номеров, а также 1С:ЗУП (для автоматизированного формирования табелей) в единую систему, удобную для обслуживания и масштабирования;

• Организовать отказоустойчивый кластер для хранения годового архива записей СВН с системой резервирования;

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

Для реализации столь масштабной модернизации потребовалось заменить PERCo-S-20 на версию PERCo-Web, поскольку S20 не поддерживала работу с терминалами распознавания лиц, системой распознавания автомобильных номеров и не позволяла подключать охранную систему.

Интеграция с 1С:ЗУП

После перехода на PERCo Web неожиданно некорректно функционировал модуль интеграции данных СКУД с системой 1С:ЗУП (наш проект наложился на другой проект заказчика по переносу кадрового учета из 1C:УПП в 1С:ЗУП и старая система PERCo-S-20 была интегрирована с УПП). Инженеры PERCo не смогли оперативно определить причину этой проблемы, поэтому пришлось подключить наших разработчиков 1С.

В ходе анализа и тестирования модуля интеграции PERCo с 1С выяснилось, что он некорректно заполняет табели учета рабочего времени, ошибочно определяя работающих и неработающих сотрудников. Выгрузка данных постоянно прерывалась из-за ошибок, которые приходилось исправлять вручную и документировать. Кроме того, в разных разделах PERCo отображалась противоречивая информация: например, в табелях показывались одни данные, а в календаре — другие. При этом данные в календаре оказывались более точными, чем в табелях, что добавляло путаницы.

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

Особенности хранения биометрии

Биометрические терминалы (ZKTeco) также стали небольшой проблемой и потребовали значительных усилий для настройки и интеграции. Основная сложность заключалась в том, что каждый терминал функционировал на основе собственной локальной базы биометрических данных, с которой он сверялся в процессе идентификации пользователей. Это создавало серьезные трудности, особенно когда речь шла о синхронизации данных между терминалами и централизованной системой PERCo-Web.

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

Особенности интеграции биометрии

Процесс интеграции был организован поэтапно и с соблюдением всех технических требований. В качестве основного устройства использовался контроллер PERCo CT/L14.1, который выполняет ключевую роль в управлении системой. К этому контроллеру был подключен специализированный конвертер PERCo AC02.2, предназначенный для преобразования сигналов и обеспечения совместимости между различными компонентами системы. После этого конвертер был соединен с биометрическим терминалом, который отвечает за считывание и обработку данных пользователей. Такая схема подключения позволила обеспечить стабильное взаимодействие между устройствами, а также корректную передачу информации от терминала к контроллеру и обратно. Каждый этап интеграции требовал тщательной настройки и проверки, чтобы исключить возможные ошибки и обеспечить бесперебойную работу всей системы в дальнейшем.

Антипасс

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

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

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

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

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

Еще одна проблема, с которой пришлось столкнуться в процессе настройки системы, была связана с питанием биометрических терминалов. Интерфейс конвертера PERCo AC02.2 имеет четыре контакта: два из них предназначены для передачи данных, один — для подачи питания +12 В, а последний — земля. В тестовой системе данные подключались к соответствующим выходам контроллера, а питание подавалось через лабораторный блок питания. В таких условиях система работала стабильно, и никаких сбоев не наблюдалось. Однако при переносе конфигурации на рабочий стенд возникли серьезные проблемы.

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

Решение проблемы оказалось достаточно простым, но потребовало пересмотра схемы подключения. Когда питание терминалов подключили через контроллер, «глюки» полностью исчезли.

Перенос карт доступа сотрудников из PERCo-S-20 в PERCo-Web

На предприятии используются карты RFID формата EM-Marine, чипы которых содержат 64 бита в следующем формате:
• 8 бит — «Номер партии / ID-производителя».
• 32 бита — «Уникальный ID-карты».
• 24 бита — это четность.
В нашем случае биты четности нам не нужны, работа идет с данными из первых 8+32 битов. В системе PERCo-S-20 с карты считывается только «ID-карты». Судя по всему, в системе версии PERCo-Web данные считываются по-другому. Кроме «ID-карты» в систему попадают и первые 8 бит «ID-производителя».

Итого, не зная первых 8 бит карты, которые не передаются считывателями S-20 номера карт, ID сотрудника в базе не сконвертировать.

Пришлось менять настройки на считывателях карт, чтобы все заработало как надо.

Система видеонаблюдения

Система видеонаблюдения на объекте практически не подлежала масштабированию, что потребовало замены всего оборудования, за исключением самих камер. Были проложены новые кабели, установлены серверы и системы хранения данных (СХД), рассчитанные на хранение записей в течение одного года.

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

Для новой системы выбор пал на систему видеонаблюдения «Интеллект X». Схема реализации выглядела следующим образом: два сервера DELL PowerEdge R640 были объединены в кластер для обеспечения резервирования, на них была запущена виртуальная машина с Ubuntu, где и работает СВН «Интеллект X» с функциями распознавания номеров. К кластеру подключены две СХД Dell PowerVault ME5084: основная и резервная. Общий объем накопителей составил 1,2 Петабайта – данного объема достаточно для хранения такого количества данных со всех камер за один год.

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

Последний рубеж

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

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

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

Итоги работы

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

P.S. Отдельной заслугой считаем решение всех возникших проблем без помощи ChatGPT.

На любые уточняющие вопросы будем рады ответить в комментариях или личке.

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