Интеграция СКУД и видеонаблюдения: единый сервер или раздельный

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

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

Без интеграции СКУД фиксирует факт прохода: «карта №2317, дверь главного входа, 03:14». Видеонаблюдение в этот момент пишет картинку, но привязки между событием и кадром нет, оператор ищет нужную секунду вручную. Сшивка двух подсистем убирает этот разрыв: событие СКУД становится закладкой в видеоархиве, оператор кликает по строке журнала и сразу видит, кто реально прикладывал карту.

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

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

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

Раздельная схема - это два сервера: один под VMS с массивом дисков и сетевыми интерфейсами под камеры, второй под контроллеры СКУД и базу журналов. Между собой они общаются через API или промежуточную шину событий. Так строят инфраструктуру на крупных объектах: бизнес-центрах от 5000 квадратных метров, производствах, логистических хабах, медицинских и учебных кампусах.

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

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

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

ONVIF интеграция - основной стандарт обмена между IP-камерами и VMS, а в расширенных профилях и между VMS и системами СКУД. Профиль S отвечает за передачу видеопотока, профиль G - за работу с архивом, профиль C добавляет события контроля доступа. Если оборудование заявляет ONVIF, это ещё не значит, что интеграция «из коробки» полная: реально совместимый набор функций сверяется по официальной матрице совместимости вендора VMS и проверяется на стенде через ONVIF Device Manager или ONVIF Test Tool - бесплатные утилиты, которые показывают, какие именно методы стандарта действительно реализованы в конкретной модели камеры и в конкретной версии VMS.

OPC UA применяется реже и преимущественно на промышленных объектах, где видеонаблюдение нужно связать с АСУ ТП и пожарной сигнализацией. Это современный преемник классического OPC DA: кросс-платформенный, с встроенной безопасностью (шифрование, аутентификация) и работой через TCP, а не через DCOM. К 2026 году новые промышленные интеграции делают именно на OPC UA, а старый OPC DA остаётся только в существующих контурах, которые ещё не мигрировали. Прямые API производителей - самый гибкий путь: интеграция СКУД и VMS через REST или WebSocket позволяет передавать события доступа в видеоархив с миллисекундной точностью, прицеплять к ним кадры и метаданные карт. Но это требует разработки и сопровождения интеграционного слоя.

Практический выбор такой: ONVIF, когда оборудование и VMS из числа массовых решений. OPC UA, когда объект промышленный и подсистемы шире, чем только видео и СКУД. Прямой API, когда нужны сложные сценарии вроде сопоставления лиц в кадре с базой пропусков и автоматических действий по правилам.

Граница раздельной схемы проходит примерно по 100–120 камерам и нескольким десяткам точек прохода. Ориентир сложился из практики: при таком числе IP-камер один сервер с типовой OLTP-нагрузкой VMS уже устойчиво держит 600–800 МБ/с дискового потока и сотни IOPS на запись, и любая просадка по записи видеоархива начинает влиять на отклик контроллера дверей. Конкретное число зависит от разрешения камер, битрейта и сценариев аналитики, но порог в районе сотни камер - рабочий маркер, после которого подсистемы пора разносить.

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

Если объект относится к КИИ или ГИС, к серверу добавляются требования ФСТЭК: сертифицированные средства защиты, изоляция сегмента, аттестация. На таких объектах единый сервер чаще проигрывает раздельной схеме - каждой подсистеме проще пройти аттестацию отдельно.

Интеграция СКУД и видеонаблюдения сокращает время расследования инцидента с часов до минут и убирает споры о том, кто реально приложил карту: на каждом эпизоде вместо ручного поиска по видеоархиву - клик из журнала. Единый сервер уместен на объектах до 80–100 камер с понятной нагрузкой, раздельная схема - на крупных объектах, в КИИ и там, где подсистемы развиваются независимо. Перед покупкой стоит зафиксировать число камер и точек прохода на горизонте трёх лет, требования по 152-ФЗ, целевую схему интеграции и подобрать оборудование СКУД с учётом протоколов, которые поддерживает выбранная VMS. На этих четырёх вводных собирается рабочая система - без переделок на этапе пусконаладки и переписывания политик после первой проверки.