Видеонаблюдение для ЖК: восстановить один инцидент через двор, подъезд и парковку

Автомобиль въехал на территорию, остановился у корпуса, человек прошёл через двор, вошёл в подъезд, поднялся к лифту. Или наоборот: событие началось в подъезде, продолжилось во дворе и закончилось на парковке.

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

Поэтому для ЖК мы проектируем не только точки камер. Мы проектируем переходы события между зонами, структуру каналов, единое время, архив и роли доступа — чтобы оператор или УК могли восстановить нужный эпизод без догадок.

Пришлите план ЖК с корпусами, подъездами, въездами, двором и парковкой. Отметим не только камеры, но и переходы, где событие не должно теряться.

У большого жилого объекта есть разные видеосценарии:

• въезд на территорию;

• двор;

• детская/общая зона;

• вход в подъезд;

• лифтовой холл;

• лестница;

• парковка;

• служебный проезд;

• периметр;

• мусорная/хозяйственная зона.

Ошибка — считать, что если каждая из этих зон «закрыта камерой», система уже целая.

Для эксплуатации важнее:

• одинаковое время;

• понятные названия;

• известная принадлежность к корпусу/подъезду;

• переходы между соседними камерами;

• доступ нужной роли;

• общий принцип поиска архива.

Для проекта выбираем несколько типовых сценариев.

Например:

Автомобиль

въезд → двор/проезд → парковка → выезд.

Человек

двор → вход в корпус → лифтовой холл.

Курьер/гость

вход на территорию → нужный корпус → входная группа.

Спор во дворе

общая зона → ближайший проход → вход в корпус/выход с территории.

Хозяйственный инцидент

служебная зона → маршрут персонала/подрядчика → точка завершения.

Для каждого сценария спрашиваем: на какой камере событие появляется и на какой должно продолжиться?

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

Названия «Camera 41», «Camera 42», «Camera 43» работают только пока инженер помнит объект.

Для ЖК полезнее иерархия.

Например:

КОРПУС 2 → ПОДЪЕЗД 3 → ВХОД С УЛИЦЫ → ЛИФТОВОЙ ХОЛЛ

или:

КОРПУС 4 → ПАРКОВКА -1 → РЯД B → ВЪЕЗД НА РАМПУ

Правила именования должны быть согласованы до массового добавления камер.

Он влияет не на качество картинки, а на скорость расследования.

Отдельный проект видеонаблюдения подъезда подробно рассматривает локальные ракурсы входа, тамбура и лифта.

Внутри конкретного подъезда отдельно решаются:

• контровой свет;

• входная дверь;

• тамбур;

• лифт;

• вандалозащита;

• локальные слепые зоны.

Задача общей системы ЖК начинается на границе: какая камера двора передаёт событие камере входа и как дальше найти нужный подъезд в общем архиве.

Для парковки нужен собственный маршрут автомобиля — это отдельная задача.

В ЖК мы проверяем другой стык:

• автомобиль идентифицирован/замечен на въезде;

• далее найден на внутреннем проезде;

• затем в парковке;

• после остановки человек может продолжить маршрут к лифту/подъезду.

LPR, обзорная парковочная камера и подъездная камера решают разные задачи, но временная шкала и правила именования должны позволить связать их в одну историю.

Централизованный архив удобен общей точкой поиска и управления.

Распределённый может быть рациональнее на многокорпусной/сложной топологии, если узлы физически разделены или нужна локальная устойчивость.

Поэтому до выбора задаём вопросы:

• сколько корпусов;

• где сетевые узлы;

• какие связи между ними;

• где работают операторы;

• какие роли должны видеть какие камеры;

• какой срок хранения требуется по эксплуатационной задаче;

• что должно продолжить работать при потере связи между корпусами;

• как будет происходить обслуживание.

Для всего ЖК фиксируем архитектурное решение. Подробный расчёт объёма в терабайтах, битрейта и срока хранения выполняется отдельно при проектировании архива.

В ЖК могут быть разные пользователи системы:

• администратор;

• диспетчер/охрана;

• сотрудник УК;

• сервисный инженер;

• иной ограниченный пользователь, если такой доступ предусмотрен заказчиком.

Для каждой роли определяем:

• какие группы камер видит;

• просмотр в реальном времени или архив;

• может ли экспортировать;

• может ли менять настройки;

• срок/способ выдачи доступа;

• кто отключает доступ при смене сотрудника/подрядчика.

Кому предоставлять доступ, определяет заказчик с учётом применимых требований.

Мы решаем инженерную часть: система должна технически позволять не раздавать полный административный доступ всем подряд.

Конкуренты часто продают модель «все жильцы видят двор/подъезд в приложении».

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

До реализации нужно определить:

• какие камеры могут быть доступны этой группе;

• только просмотр в реальном времени или также архив;

• есть ли индивидуальные аккаунты;

• кто управляет жизненным циклом пользователей;

• что происходит при смене жильца/собственника/договора;

• через какую платформу работает доступ;

• как отделены служебные камеры/технические зоны.

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

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

Вопросы при проектировании:

• какие камеры исчезнут у центрального оператора;

• продолжится ли локальная запись, если она предусмотрена архитектурой;

• какие сервисы зависят от центрального узла;

• как инженер поймёт, где отказ;

• есть ли понятная схема магистральных соединений, корпусов и шкафов.

Оптический бюджет, подбор SFP и правила VLAN требуют детального проектирования соответствующих подсистем.

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

Для восстановления события по нескольким зонам нужны согласованные временные метки.

Если камера двора показывает 18:42:10, камера подъезда — 18:46:40 для того же события, а парковка живёт в третьем времени, оператору приходится угадывать.

Поэтому при сдаче проверяем согласованность времени и часового пояса между ключевыми узлами.

Подробный проект синхронизации NTP выполняется отдельно.

Полезный сценарий приёмки выглядит так.

Инженеру дают только исходную информацию, например:

«Автомобиль въехал примерно в 20:10, человек вышел у корпуса 3 и вошёл в подъезд».

Дальше он должен:

1. найти исходную точку поиска;

2. определить точное время;

3. перейти на следующую камеру;

4. определить корпус/зону;

5. продолжить маршрут до подъезда;

6. найти нужный эпизод;

7. при необходимости перейти в парковочную цепочку;

8. экспортировать только относящиеся к событию фрагменты;

9. передать результат в согласованном порядке.

Если для этого нужно звонить монтажнику и спрашивать «какая из Camera 78 смотрит на корпус 3», система ещё не принята как удобная для эксплуатации.

Тест 1 — въезд → двор

Автомобиль/человек появляется в исходной зоне и уверенно продолжается в следующей.

Тест 2 — двор → подъезд

Проверяем нужный корпус, вход и временную связность.

Тест 3 — парковка → подъезд/лифт

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

Тест 4 — корпус A → центральное рабочее место

Проверяем просмотр в реальном времени, работу с архивом и доступ по согласованной роли.

Тест 5 — ограниченная роль

Пользователь видит только тот набор функций/камер, который ему назначен.

Тест 6 — архив

По условию без заранее подготовленного времени оператор находит событие.

Тест 7 — экспорт

Проверяется короткий реальный фрагмент.

Тест 8 — восстановление работы

После согласованного перезапуска/восстановления узла камеры возвращаются в штатную эксплуатацию согласно архитектуре.

Не только пароль и схема камер.

Полезный комплект для передачи системы ЖК в эксплуатацию:

• план корпусов и зон;

• правила именования камер и каналов;

• таблица камера → корпус → подъезд → зона;

• схема основных сетевых узлов;

• ответственный за каждую подсистему проекта;

• роли пользователей;

• архивная структура;

• точки перехода между зонами наблюдения;

• список критичных межкорпусных связей;

• результаты межзоновых тестов;

• ограничения;

• список резервных/свободных ресурсов для расширения;

• порядок передачи в обслуживание.

Так система остаётся понятной после смены подрядчика или сотрудника УК.

Нужно спроектировать только вход/лифты одного подъезда? → «Видеонаблюдение для подъезда».

Нужно восстановить путь автомобиля по парковке? → «Видеонаблюдение для парковки».

Нужно читать номера на въезде? → «Распознавание автомобильных номеров».

Нужна логика домофонных вызовов и открытия двери? → «Домофония».

Нужно управлять физическим доступом через считыватели/замки? → «СКУД».

Нужно рассчитать оптическую магистраль? → «Оптика для видеонаблюдения».

Нужно вычислить глубину архива? → «Архив видеонаблюдения».

Система ЖК соединяет эти подсистемы на уровне эксплуатации, сохраняя необходимость отдельной инженерной проработки каждой из них.

Полезно прислать:

• генплан/план ЖК;

• число корпусов;

• число подъездов;

• этажность в объёме задачи;

• въезды/выезды;

• парковки;

• существующие камеры;

• существующие NVR/VMS/серверы;

• сетевые шкафы и узлы, если известны;

• кто должен пользоваться системой;

• нужен ли доступ отдельным пользовательским группам;

• желаемый срок архива;

• один-два реальных сценария, которые сейчас расследовать сложно.

Лучший исходный вопрос:

«Какой инцидент мы сегодня не можем быстро проследить от первой зоны до последней?»

Цена зависит не только от числа камер.

На состав решения влияют:

• количество корпусов/подъездов;

• число переходов между зонами;

• распределённость сетевых узлов;

• парковка/въезды;

• существующая инфраструктура;

• архив;

• число операторских/ролей;

• пользовательский доступ;

• межкорпусные магистрали;

• интеграции;

• необходимость модернизации действующих систем;

• объём документации и тестирования.

Без плана и модели эксплуатации мы не публикуем фиктивную цену «за ЖК».

Отправьте план ЖК и один реальный сценарий инцидента. Сначала построим цепочку зон и ролей, а уже после этого станет понятно, сколько камер, узлов и архива действительно нужно.

Сколько камер нужно для жилого комплекса?

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

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

Нет. Это отдельное решение проекта. Состав пользователей и их полномочия определяет заказчик; технически система позволяет разделить роли и не выдавать один полный административный доступ всем пользователям.

Нужен один центральный сервер?

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

Можно объединить камеры разных корпусов в одну систему?

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

Нужна ли LPR-камера на въезде?

Только если номер действительно должен быть отдельным идентификатором/событием. Общая камера въезда и LPR решают разные задачи.

Что важнее для большого ЖК — разрешение камер или архив?

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