Инцидент в офисе случился ночью, а к утру служба безопасности всё ещё собирает картину: журналы СКУД лежат в одном архиве, видеоархив в другом, время на серверах разъехалось на сорок секунд, и попытка наложить «кто прошёл» на «что в кадре» превращается в ручной разбор. Интеграция СКУД и видеонаблюдения нужна именно для того, чтобы такие сценарии разбирались за минуты, а не за смену.
Вопрос звучит просто: ставить один сервер на обе подсистемы или два разных. Ответ зависит от масштаба объекта, требований к надёжности и того, кто потом будет это эксплуатировать. Разберём оба варианта, требования к железу и протоколы, через которые подсистемы реально начинают разговаривать.
Что даёт связка СКУД и видеонаблюдения на одном объекте
Без интеграции СКУД фиксирует факт прохода: «карта №2317, дверь главного входа, 03:14». Видеонаблюдение в этот момент пишет картинку, но привязки между событием и кадром нет, оператор ищет нужную секунду вручную. Сшивка двух подсистем убирает этот разрыв: событие СКУД становится закладкой в видеоархиве, оператор кликает по строке журнала и сразу видит, кто реально прикладывал карту.
Польза не ограничивается расследованиями. На проходных интеграция позволяет автоматически фиксировать ситуации передачи карты, когда лицо в кадре не совпадает с владельцем пропуска. На складах связка СКУД и видеонаблюдения сокращает число спорных эпизодов с поставщиками. В офисах с гибридным графиком отдел персонала получает достоверные данные о посещаемости. Технически всё это требует двух условий: единого времени между подсистемами и общего канала событий, по которому СКУД и видео обмениваются метаданными.
Единый или раздельный сервер: сравнение архитектур
Единый сервер СКУД и видеонаблюдения
Архитектура с одним сервером означает, что VMS и контроллер СКУД крутятся на одной физической машине либо в одной виртуальной среде на общем гипервизоре. Журналы хранятся в одной базе, время гарантированно синхронизировано, события связываются на уровне платформы - без шин и шлюзов. Для объектов малого и среднего масштаба это удобно: меньше точек отказа в эксплуатации, один контракт на поддержку, один администратор закрывает обе подсистемы.
Минусы тоже понятны. Видеонаблюдение требовательно к дисковой подсистеме и сети, СКУД - к стабильности и быстрому отклику на события доступа. Когда видеоархив активно пишется, ресурсы общего сервера расходуются на запись потоков и могут просесть отклик контроллера дверей. На объекте с десятком камер это не критично, на сотне - становится узким местом.
Раздельные серверы для СКУД и видеонаблюдения
Раздельная схема - это два сервера: один под VMS с массивом дисков и сетевыми интерфейсами под камеры, второй под контроллеры СКУД и базу журналов. Между собой они общаются через API или промежуточную шину событий. Так строят инфраструктуру на крупных объектах: бизнес-центрах от 5000 квадратных метров, производствах, логистических хабах, медицинских и учебных кампусах.
Преимущества - независимая отказоустойчивость подсистем и возможность масштабировать видеохранение, не трогая СКУД. Минусы - выше суммарная стоимость владения, нужны компетенции по обеим платформам, обязательна синхронизация времени через NTP и согласованный набор протоколов. Без этого «два сервера» превращаются в «две отдельные подсистемы, которые иногда обмениваются файлами».
Сервер для видеонаблюдения: требования к железу
Сервер для видеонаблюдения отличается от обычного офисного сервера по трём направлениям: дисковая подсистема, сетевые интерфейсы, ресурс CPU и оперативной памяти под VMS. На каждом из них есть типовые ошибки, которые потом дорого исправлять.
- Диски. Для записи видеопотоков нужны накопители класса Surveillance или Enterprise, рассчитанные на круглосуточную запись 24/7. SSD под архив избыточны, но обоснованы под кеш и под базу событий VMS. Объём считается из битрейта камеры, числа камер и срока хранения по 152-ФЗ или внутреннему регламенту.
- Сеть. На каждые 30–40 IP-камер закладывают отдельный сетевой интерфейс 1 Гбит/с или агрегированный канал, для камер 4K с битрейтом от 8 Мбит/с порог ниже. Желательна выделенная VLAN под видео, чтобы поток не делил полосу с офисным трафиком.
- CPU и память. Современные VMS - Trassir, Macroscop, ITV, параллельно декодируют потоки и крутят видеоаналитику. На 50 камер с базовой детекцией движения хватает 8–10 ядер, под распознавание лиц или номеров расчёт делается отдельно.
- Резервирование. RAID 5 или RAID 6 на массиве архива, источник бесперебойного питания на 10–15 минут под штатное завершение, дублированный блок питания на сервере.
Под типовые задачи удобно смотреть готовые серверы видеонаблюдения с подобранным балансом дисков, сети и CPU - это снимает половину вопросов по конфигурации на старте проекта.
Протоколы интеграции СКУД и видеонаблюдения
ONVIF интеграция, OPC и API
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, когда нужны сложные сценарии вроде сопоставления лиц в кадре с базой пропусков и автоматических действий по правилам.
Сценарии, где единый сервер СКУД и видеонаблюдения уместен
- Офисное здание до 50 камер и 20 точек прохода. Один сервер на VMS и СКУД закрывает задачу с запасом, эксплуатация - силами одного администратора.
- Розничные точки сети с 8–15 камерами на магазин. Локально один сервер на магазин, централизованный мониторинг сверху - типовая схема для розничных сетей.
- Образовательные учреждения: школы и колледжи на 30–60 камер с учётом классов и коридоров. Бюджетные ограничения и небольшой штат ИТ делают единый сервер логичным выбором.
- Складской комплекс до 80 камер при стабильном потоке событий доступа. Единый сервер допустим, если архитектор закладывает запас по дисковой подсистеме и сети.
- Бизнес-центр класса B с одной управляющей компанией. Если арендаторы не требуют отдельных контуров видео, единая платформа упрощает обслуживание.
Граница раздельной схемы проходит примерно по 100–120 камерам и нескольким десяткам точек прохода. Ориентир сложился из практики: при таком числе IP-камер один сервер с типовой OLTP-нагрузкой VMS уже устойчиво держит 600–800 МБ/с дискового потока и сотни IOPS на запись, и любая просадка по записи видеоархива начинает влиять на отклик контроллера дверей. Конкретное число зависит от разрешения камер, битрейта и сценариев аналитики, но порог в районе сотни камер - рабочий маркер, после которого подсистемы пора разносить.
Безопасность данных и требования 152-ФЗ
И видеозапись с лицами, и журналы СКУД с табельными номерами попадают под 152-ФЗ. Сервер с этими данными размещается в защищённом сегменте сети, доступ к нему - по ролям, действия операторов фиксируются в журнале аудита. Срок хранения видеоархива определяется внутренним регламентом, минимально - 30 суток для большинства коммерческих объектов.
Если объект относится к КИИ или ГИС, к серверу добавляются требования ФСТЭК: сертифицированные средства защиты, изоляция сегмента, аттестация. На таких объектах единый сервер чаще проигрывает раздельной схеме - каждой подсистеме проще пройти аттестацию отдельно.
Антипаттерны при интеграции
- Поставить один сервер на 200+ камер ради экономии и закрыть глаза на узкое место в дисковой подсистеме;
- Сэкономить на синхронизации времени по NTP с общим источником: расхождение в 40 и более секунд между журналом СКУД и видеоархивом делает функцию «клик по строке журнала → нужный кадр» бесполезной - оператор всё равно ищет вручную, а сама идея интеграции теряет смысл;
- Купить «совместимое по ONVIF» оборудование без проверки матрицы реальной совместимости с VMS;
- Хранить видеоархив на офисных дисках без класса Surveillance - выход из строя в первый год эксплуатации.
Заключение
Интеграция СКУД и видеонаблюдения сокращает время расследования инцидента с часов до минут и убирает споры о том, кто реально приложил карту: на каждом эпизоде вместо ручного поиска по видеоархиву - клик из журнала. Единый сервер уместен на объектах до 80–100 камер с понятной нагрузкой, раздельная схема - на крупных объектах, в КИИ и там, где подсистемы развиваются независимо. Перед покупкой стоит зафиксировать число камер и точек прохода на горизонте трёх лет, требования по 152-ФЗ, целевую схему интеграции и подобрать оборудование СКУД с учётом протоколов, которые поддерживает выбранная VMS. На этих четырёх вводных собирается рабочая система - без переделок на этапе пусконаладки и переписывания политик после первой проверки.
