Городское и публичное видеонаблюдение: дизайн

Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Городское и публичное видеонаблюдение определяют две нагрузки, которые ни один другой сценарий не доводит до предела одновременно, – чистый масштаб (тысячи и десятки тысяч камер, много вендоров, районов и ведомств) и самый тяжёлый в отрасли вес приватности и закона, потому что камеры смотрят на публику в местах, которых не избежать. Масштаб решается федерацией, а не одной гигантской системой: каждый район пишет свои камеры локально, а центр открывает их по запросу, ведь попытка свести все потоки в один дата-центр потребовала бы десятков гигабит в секунду, а единый сбой ослепил бы весь город. Хранение – задача на петабайты: город на 5000 камер при скромных 2 Mbps на камеру пишет около 108 ТБ в сутки, примерно 3,2 ПБ за 30 суток хранения до накладных расходов на отказоустойчивость, – поэтому бюджет задают срок хранения, режим записи и уровни хранения. Вес приватности недооценивают чаще всего: распознавание лиц публики в реальном времени – это черта, которую нельзя пересекать беспечно: для полиции в общественных местах оно запрещено EU AI Act, лишь с узкими исключениями по санкции суда, и подпадает под особые правила биометрии в GDPR, так что комплаенс – это архитектурное решение первого дня, а не функция, включаемая потом.

Почему это важно

Если вы проектируете, закупаете или строите видеонаблюдение для города, транспортного предприятия, порта, стадионного квартала или программы «безопасный город», это самая крупная и ответственная система, которую вам придётся оценивать, – и та, где неверное допущение дороже всего, потому что её оплачивают из общественных денег и за неё отвечают публично. Рынок городского видеонаблюдения в 2026 году составил около 15,6 млрд долларов и растёт примерно на 8% в год, и заказчики – уже не только полиция: дорожные службы, транспорт, экстренные службы и частные владельцы камер сводят потоки в общие центры мониторинга. Эта статья – вендоронейтральный референс-дизайн городского наблюдения: как федерировать тысячи камер по районам, как на этом масштабе реально считается хранение и канал, что аналитика делает на самом деле и, главное, где проходят правовые черты вокруг наблюдения за публикой, – чтобы вы спроектировали систему, которая переживёт и общегородской инцидент, и судебный иск. Она собирает блоки из остального курса, а не повторяет их, и тратит свои слова на уникальное для города: масштаб и приватность на пределе.

Две нагрузки, определяющие городскую систему

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

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

Вторая нагрузка – вес приватности и закона. Магазин снимает своих покупателей на своей территории; завод – свой двор. Город снимает всех, в местах, которых не миновать, и часто без реальной возможности отказаться. Это самая зарегулированная деятельность во всём видеонаблюдении, и право вокруг неё двигалось быстро. Технически отличный, но юридически беспечный городской дизайн не разворачивают – его блокируют по иску, лишают финансирования или отключают после общественного возмущения. Поэтому приватность – не глава в конце проекта, а ограничение архитектуры с первой схемы.

Нажмите, чтобы увеличить

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

Город – это много систем, а не одна

Первый порыв новичка – представить одну огромную систему управления видео (программную платформу, которая принимает, пишет и управляет множеством камер, – VMS), куда воткнуты все камеры города и где все операторы смотрят на одну карту. Этот дизайн рушится в масштабе города по двум конкретным причинам, и понимание почему – ключ ко всей архитектуре.

Первая причина – канал. Видео тяжёлое и постоянное. Пусть в городе 5000 камер, каждая даёт скромные 2 мегабита в секунду (Mbps) сжатого видео – разумное среднее для 4-мегапиксельной камеры на эффективном кодеке H.265 с умным битрейтом. Если попытаться слать каждый поток непрерывно в один дата-центр только ради записи, входящий трафик составит:

5000 камер × 2 Mbps = 10 000 Mbps = 10 Gbps, постоянно, 24/7

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

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

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

Нажмите, чтобы увеличить

Это единственное решение – пиши локально, отдавай по запросу – превращает невозможные 10 Gbps в управляемые. Вместо всех потоков в центр идут лишь те, что оператор открыл. Если пятьдесят операторов по городу смотрят по одной камере на 4 Mbps, это 200 Mbps живого просмотра, а не 10 Gbps записи. Остальное остаётся в районе, где его сняли.

«Частая ошибка: проектировать город как одну централизованную VMS, потому что так проектируют одно здание. На слайде это выглядит проще, а на деле разваливается – стоимость канала абсурдна, центр становится единой точкой отказа города, а первый перерубленный кабель уносит целый район. Масштаб города – это задача федерации. Стройте много малых автономных систем и координируйте их, а не одну гигантскую.»

Хранение – это задача на петабайты

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

Хранение из видеопотока – это просто битрейт, умноженный на время. Один мегабит в секунду при непрерывной записи даёт предсказуемый объём в сутки:

1 Mbps = 0,125 мегабайта в секунду
0,125 МБ/с × 86 400 секунд в сутки = 10 800 МБ = 10,8 ГБ в сутки

То есть каждый 1 Mbps непрерывной записи – это около 10,8 ГБ на камеру в сутки. Масштабируем на наш город из 5000 камер при среднем 2 Mbps:

На камеру:   2 Mbps × 10,8 ГБ = 21,6 ГБ на камеру в сутки
Весь город:  21,6 ГБ × 5000 камер = 108 000 ГБ = 108 ТБ в сутки
30 суток:    108 ТБ × 30 = 3240 ТБ ≈ 3,2 ПБ

Три и две десятых петабайта за один месяц записи – и это полезный объём. Реальное хранилище добавляет избыточность, чтобы отказ диска не терял видео (RAID, обычно ×1,4–1,6), и запас, чтобы массив не работал под завязку, – это поднимает сырое требование к ~5 ПБ. Город, что хранит 90 суток вместо 30, утраивает цифру. Поэтому в масштабе города важнее характеристик камеры три рычага:

• Срок хранения – самый большой множитель. Хранить вдвое дольше стоит вдвое больше места. Правильное число задаётся законом и нуждой, а не тем, сколько влезло на диски, – см. политика хранения: сколько хранить видео.
• Режим записи меняет счёт. Непрерывная запись пишет всё; запись по движению или событию на менее важных камерах заметно сокращает их след. Полное уравнение хранения и его рычаги – в статье хранение видеонаблюдения и расчёт ретенции.
• Уровни хранения переносят старое видео с быстрого дорогого диска на медленный дешёвый архив по мере старения, чтобы не платить премиум за хранение прошлонедельных пустых коридоров. См. уровни хранения: горячий, тёплый, холодный, архив.

Нажмите, чтобы увеличить

Поскольку хранение доминирует в стоимости, планирование ёмкости на этом масштабе не опционально – серверы записи считают по устойчивой скорости записи, а не только по числу камер, и каждый ресурс (хранение, сеть, сервер, клиент) упирается в свой предел в разной точке. Метод разобран в статье масштабирование VMS: планирование ёмкости, а как превратить дизайн в число – в оценке проекта видеонаблюдения.

Стандартный каркас, что держит разнородный город вместе

Городской парк никогда не из одного бренда. Камеры приходят за десятилетие отдельных закупок, от разных производителей, в разных районах. Единственное, что не даёт этому стать десятками несовместимых силосов, – общий стандарт, и в видеонаблюдении это ONVIF – общий язык, на котором камеры и ПО записи от разных производителей понимают друг друга.

ONVIF работает через профили, каждый покрывает свой кусок: Profile S – живой поток, Profile G – запись и поиск, Profile T – продвинутый поток вроде H.265, Profile M – метаданные аналитики и события (канал, которым камера сообщает VMS «транспорт вошёл в зону»). Для города ONVIF – это то, что даёт камерам нового района войти в платформу без отдельной интеграции под каждую модель. Но помните ограничение, проходящее через весь курс: ONVIF гарантирует базис, на который согласны оба устройства, а не полный паритет функций. Самая продвинутая аналитика камеры часто всё равно требует собственного SDK вендора. Держите «работает по ONVIF» и «все функции работают по ONVIF» раздельно – в голове и в договорах. Полная картина – в статье ONVIF для инженеров, а полезным дополнением будет коммерческий обзор профилей ONVIF в системах безопасности, стоящий на позиции 1.

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

Что аналитика делает на самом деле в масштабе города

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

Дорожная и транспортная аналитика – рабочая лошадка. Автоматическое распознавание номеров (в Великобритании ANPR, в США LPR) читает номера для управления трафиком, контроля полос и выделенных полос, для поиска угнанных и разыскиваемых машин. Масштаб реален: национальная сеть ANPR в Великобритании работает на порядка 13 000 камер, подающих примерно 55–60 миллионов «прочтений» номеров в сутки. Номер – персональные данные, но не особая биометрия, поэтому правовой вес смещён на хранение и доступ, а не на захват, – различие мы аккуратно проводим в статье распознавание автомобильных номеров (LPR/ANPR).

Аналитика толпы и движения считает людей, оценивает плотность и помечает необычный поток – толпу, растущую выше безопасного порога у транспортного узла, человека против потока, оставленный предмет. Это правила и счёт, они в целом описывают сцену, не опознавая никого; логика правил – в статье поведенческая аналитика: праздношатание, вторжение, зоны, а ремесло подсчёта людей – в референс-дизайне ритейл-аналитики.

Форензик-поиск – аналитика, которой операторы пользуются чаще всего. После инцидента вы не отматываете тысячи часов записи – вы запрашиваете индекс метаданных, построенный во время записи по всему федеративному парку («красный фургон, этот коридор районов, между 14:00 и 16:00»). Что вы найдёте, целиком зависит от того, что было проиндексировано; метод и его пределы – в статье поиск по событию и форензик-поиск.

Запускайте всё это на краю, где можно – на камере или сервере района, – чтобы аналитика рождала маленькие метаданные, а не гнала полное видео в центр. Так сохраняется федеративный бюджет канала, и это та же логика edge-против-облака, что мы изложили в аналитике на краю против облака. И никогда не называйте одну цифру точности ни для одной из них. Точность аналитики – это диапазон precision/recall, зависящий от ракурса, освещения, погоды и настройки; распознаватель номеров на контролируемой полосе куда надёжнее той же модели на свободном ночном трафике.

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

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

Начните с различия, потому что вендоры его размывают. Детекция лица («здесь есть лицо») – это не распознавание лица («это лицо принадлежит такому-то, сверено со списком»). Распознавание превращает лицо в биометрический шаблон – строку чисел, уникальную для человека, – и сверяет её с базой. Этот шаблон – особая категория биометрических данных по Общему регламенту ЕС о защите данных (GDPR, Regulation (EU) 2016/679), а именно по статье 9, что запрещает обрабатывать его ради уникального опознания человека, кроме узких условий. Внутренности модели – как лицо становится шаблоном – относятся к разделу AI for Video Engineering; здесь же суть – правовой барьер, и закон о публичном распознавании лиц теперь прямой.

Регламент ЕС об искусственном интеллекте (EU AI Act, Regulation (EU) 2024/1689), чьи запреты действуют с 2 февраля 2025 года, в статье 5(1)(h) запрещает использование систем биометрической идентификации в реальном времени в общественных местах для целей правоприменения – ровно сценарий «живое распознавание лиц на городской улице» – с лишь тремя исчерпывающе перечисленными исключениями: целевой поиск конкретных жертв похищения, торговли людьми или сексуальной эксплуатации либо пропавших; предотвращение конкретной, существенной и неминуемой угрозы жизни или предвидимого теракта; и установление местонахождения или личности подозреваемого в тяжком преступлении из списка Регламента. Даже в этих исключениях развёртывание требует предварительной санкции судебного или независимого административного органа, оценки влияния на основные права и регистрации в базе данных ЕС. Регламент отдельно запрещает создавать базы лиц нецелевым сбором изображений из интернета или с камер. Биометрическая идентификация вне этого запрета (например, постфактум или неполицейскими акторами по GDPR) отнесена к высокому риску с тяжёлым режимом обязанностей; эти обязанности высокого риска планировались на 2 августа 2026 года, но были отложены до 2 декабря 2027 года в рамках упрощающего пакета «Digital Omnibus», предварительно согласованного 7 мая 2026 года, – дату стоит перепроверять, потому что эта часть права ещё движется.

Нажмите, чтобы увеличить

За пределами ЕС картина дробная, но не менее ограничивающая. В Великобритании решение Апелляционного суда по делу Bridges против полиции Южного Уэльса ([2020] EWCA Civ 1058) признало развёртывание полицейского распознавания лиц в реальном времени незаконным – не потому что технология запрещена, а потому что правовая рамка вокруг того, кого можно вносить в список и где применять, была слишком рыхлой, нарушая право на частную жизнь, обязанности по защите данных и публичную обязанность равенства. С тех пор Великобритания расширила распознавание лиц под более жёсткой политикой, а регулятор проверяет силовиков по отдельности – напоминание, что правило для публики звучит как «конкретно, необходимо, соразмерно и подотчётно», а не «включено по умолчанию». В США федерального правила нет, поэтому города законодательствуют сами: Сан-Франциско стал первым городом, запретившим государственное использование распознавания лиц в мае 2019 года, и больше десятка городов США последовали, тогда как другие его разрешают, – значит, одна и та же аналитика законна по одну сторону границы округа и преступна по другую. А биометрические законы штатов США, прежде всего иллинойсский BIPA, привязывают серьёзную ответственность к захвату биометрии без согласия, как мы разбираем в статье BIPA и биометрические законы США.

И последний пункт о точности, потому что он усугубляет правовой. Распознавание лиц, дающее высокие 90-е проценты в кооперативном лабораторном тесте – хороший свет, человек смотрит в камеру, – работает заметно хуже на реальном уличном видео с расстояния, в толпе, при плохом свете, и национальное тестирование задокументировало значимые различия точности между демографическими группами. Ложное совпадение в городе – не статистика, а реальный человек, задержанный за то, чего не делал. «Точного на 100%» распознавания лиц не бывает, и город, что разворачивает его так, будто бывает, строит и юридическую, и правозащитную ответственность. Более глубокий разбор – в статье распознавание лиц в видеонаблюдении.

Privacy by design – это и есть архитектура города

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

Законное основание и задокументированная цель. Госоргану нужно ясное правовое основание и определённая цель для каждой камеры и аналитики, и камеры должны смотреть не шире, чем требует цель. Рамка ЕС для этого – основание законного интереса или публичной задачи, тест необходимости и соразмерности, обязанность минимизировать захват – изложена в Guidelines 3/2019 Европейского совета по защите данных (EDPB) об обработке персональных данных через видеоустройства и опирается на GDPR. Полный разбор – в статьях GDPR для видеонаблюдения и privacy by design для видеонаблюдения.

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

Маскирование приватности. Камеры, что неизбежно захватывают окна, сады или интерьеры, за которыми системе незачем смотреть, должны иметь эти области цифрово зачернёнными в источнике. Маскирование – это принцип минимизации данных, сделанный конкретным.

Хранение и законное удаление. Видео хранят не дольше, чем требует цель; принцип ограничения хранения в GDPR (статья 5(1)(e)) задаёт максимум, отличный от любого операционного минимума. В масштабе петабайт автоматическое журналируемое удаление по расписанию – это не только комплаенс, но и способ не дать хранилищу расти безгранично. Системы ANPR показывают дисциплину: прочтения держат заданный срок с многоуровневыми лимитами доступа, а не вечно.

Многоведомственный доступ и аудит. Городская система общая – полиция, транспорт, экстренные службы, иногда частные владельцы камер. Каждая роль должна видеть лишь то, на что имеет право (ролевой доступ), и каждый просмотр, поиск и выгрузка должны журналироваться, чтобы злоупотребление можно было выявить и доказать. Общий центр мониторинга силён именно тем, что сводит потоки; эта сила и есть причина инженерить управление доступом, а не предполагать его.

Вся эта позиция собрана как упорядоченный предзапусковый список в статье чек-лист комплаенса видеонаблюдения – правильный спутник этого дизайна на стадии юридической проверки. (Российским командам стоит держать рядом и местный аналог – 152-ФЗ «О персональных данных», – но первичная правовая рамка этой статьи остаётся GDPR/EU AI Act.)

Рабочий референс-дизайн: город на 5000 камер в шести районах

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

Архитектура (федеративная):
  6 узлов-районов        каждый пишет свои ~830 камер локально (edge-запись)
  Центральный пункт      ищет по всему парку, открывает любую камеру по запросу
  Роль WAN               несёт метаданные + просмотры по запросу, НЕ постоянную запись

Хранение (30 суток, в среднем 2 Mbps, H.265):
  На камеру   2 Mbps × 10,8 ГБ = 21,6 ГБ/сутки
  На район    830 камер × 21,6 ГБ ≈ 17,9 ТБ/сутки  → ~538 ТБ / 30 суток (полезных)
  Весь город  ≈ 108 ТБ/сутки     → ~3,2 ПБ / 30 суток (полезных)
  + RAID и запас (×1,5)           → ~4,9 ПБ сырых, распределённых по шести районам

Канал:
  Централизованно (отклонено)  5000 × 2 Mbps = 10 Gbps постоянного канала
  Федеративно (выбрано)        ~50 просмотров × 4 Mbps = 200 Mbps + малые метаданные

Стандартный каркас:
  ONVIF Profile S/T (поток), G (запись/поиск), M (события аналитики); IEC 62676 на уровне системы

Аналитика (сначала на краю):
  ANPR для трафика + розыск машин; толпа/поток на узлах; форензик-поиск по городу
  Распознавание лиц публики: ВЫКЛ по умолчанию — правовой барьер (EU AI Act ст. 5 / GDPR ст. 9), не переключатель

Управление (встроено, не навешано):
  DPIA до запуска (GDPR ст. 35) · маскирование в источнике · удаление по расписанию с журналом
  ролевой доступ для полиции/транспорта/служб · полный журнал просмотров, поисков, выгрузок

Числа иллюстративны и сильно двигаются с разрешением камер, кодеком, режимом записи, климатом и вендором – считайте реальный проект с моделью стоимости видеонаблюдения и чек-листом архитектуры и управления городским видеонаблюдением ниже, что кладёт решения по федерации, математику хранения и канала, стандартный каркас и правовой барьер на одну страницу. Форма дизайна, впрочем, устойчива: федерируйте по районам, чтобы город масштабировался и переживал сбои; пишите на краю и отдавайте по запросу, чтобы сеть несла просмотры, а не постоянную запись; уровняйте хранение и дисциплинируйте срок, чтобы петабайты остались посильны и законны; опирайтесь на ONVIF и IEC 62676, чтобы держать разнородный парк; и трактуйте биометрическую черту и контроль управления как архитектуру, решённую в первый день.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт строит видеостриминг, real-time-видео и компьютерное зрение с 2005 года, в 250+ проектах, и городское наблюдение лежит ровно на пересечении больших парков, жёстких ограничений потока и аналитики. Когда мы проектируем или интегрируем городскую систему, мы ведём с того, как она ведёт себя под реальной нагрузкой, – какой канал реально потребляет федеративное развёртывание, во сколько петабайт обходится выбранный срок хранения, какова честная точность аналитики на реальных ракурсах и освещении города, – и лишь затем переходим к списку функций, потому что городской дизайн, игнорирующий математику канала и хранения, рушится в момент выхода со слайда. Мы трактуем приватность и правовую позицию как архитектурное решение первого дня – маскирование, хранение и удаление, ролевой доступ и аудит, жёсткий барьер перед любой биометрической идентификацией, – чтобы система пережила и общегородской инцидент, и вопрос регулятора, а не доустраивала комплаенс после включения камер.

Главное

• Городскую систему определяют две нагрузки сразу: экстремальный масштаб и самый тяжёлый вес приватности.
• Федерируйте по районам – пишите локально, отдавайте по запросу – иначе канал и один сбой утопят её.
• Хранение – задача на петабайты: 5000 камер по 2 Mbps пишут ~108 ТБ в сутки.
• Срок хранения, режим записи и уровни – это бюджет, а не характеристики камеры.
• Распознавание лиц публики – правовая черта (EU AI Act ст. 5 / GDPR ст. 9), не переключатель.
• Privacy by design – DPIA, маскирование, хранение, доступ, аудит – это архитектура первого дня.

Что читать дальше

• Федерация: много площадок как одна – паттерн масштаба, на котором стоит этот дизайн.
• GDPR для видеонаблюдения – правовая рамка наблюдения за публикой.
• Оценка проекта видеонаблюдения: от объёма к числу – превратите этот дизайн в стоимость.