Оценка проекта видеонаблюдения: от объёма к смете

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

Кратко

Хорошая оценка проекта видеонаблюдения строится снизу вверх – от задачи, которую решает каждая камера, а не сверху вниз от заранее выбранного бюджета. Цепочка короткая и почти механическая: решите, что должна показывать каждая зона, переведите это в число камер, примените четыре множителя (разрешение, срок хранения, аналитика и модель развёртывания), чтобы получить объём хранилища и стоимость ПО, и добавьте строку, которую забывают почти все сметы, – людей, которые проектируют, монтируют и настраивают систему. Покажите арифметику на каждом шаге, и итоговое число перестаёт быть догадкой и становится обоснованным диапазоном с названными допущениями. Статья проводит всю цепочку на сквозном примере объекта на 60 камер, затем даёт реалистичный график и рабочий лист, чтобы вы прогнали такую же оценку для своего здания.

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

Если вам нужно поставить цену системе видеонаблюдения – как интегратору, который её считает, продакт-менеджеру, который её бюджетирует, руководителю объекта или ритейла, который её утверждает, или инженеру, который будет писать ПО, – задачу вам обычно дают задом наперёд. Кто-то называет бюджет или число камер, а настоящие вопросы (что должна видеть каждая камера, как долго должна жить запись, что нужно обнаруживать автоматически) остаются без ответа до последнего. Так и появляются проекты с камерами, которые слишком грубы, чтобы кого-то опознать, с хранилищем, которое забивается на три недели раньше срока, и со «сданной» системой, которую никто не настроил. Эта статья даёт обратную привычку: повторяемый способ превратить задачу в объём работ, а объём – в число, за которое вы можете отвечать, включая затраты и недели, которые сметы регулярно упускают. Цель – чтобы вы могли оценить проект, критически прочитать смету интегратора и понять, какие один-два допущения на самом деле определяют цену.

Рамка: стройте число от задачи, а не от бюджета

Любая оценка – это утверждение о причине и следствии. Слабая версия начинается с бюджета («у нас есть 100 000 $, сколько это камер?») и идёт назад, что гарантирует: что-то реальное (охват, срок хранения или настройку) тихо урежут, чтобы влезть в сумму. Сильная версия начинается с задачи, которую решает каждая камера, и стоимость вытекает из неё. С бюджетом всё равно можно сравнить – просто в последнюю очередь, когда видно, чем именно пожертвует сокращение.

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

В модели пять шагов, и дальше каждый раздел – это один шаг: превратить задачу в требования, требования – в число камер, применить четыре множителя, собрать стек затрат и разложить реалистичный график. Арифметику показываем вслух на одном сквозном примере – объекте на 60 камер (склад с торговлей), – чтобы метод оставался конкретным.

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

Шаг 1 – Превратите задачу в требования: что должна видеть каждая камера

Корень каждого последующего числа – обманчиво маленькое решение: какой уровень детализации реально нужен для каждой зоны? «Покрыть погрузочную рампу» – это не требование. «Понять, что у рампы есть машина» и «прочитать номер машины у рампы» – это разные требования, которым нужны разные камеры, и разрыв между ними может составить десять раз по числу пикселей.

В отрасли видеонаблюдения для этого есть стандартная шкала, и, освоив её, вы убираете бо́льшую часть гадания. Она называется DORI – Detection, Observation, Recognition, Identification (обнаружение, наблюдение, распознавание, идентификация) – и идёт из международного стандарта на системы видеонаблюдения IEC 62676-4. DORI сопоставляет четыре частые задачи с нужной плотностью пикселей – сколько пикселей камера кладёт на один метр сцены на том расстоянии, которое важно:

• Обнаружение – 25 пикселей на метр. Достаточно, чтобы понять, что присутствует человек или машина. Годится для широкого обзора, но не для того, чтобы понять, кто это.
• Наблюдение – около 63 пикселей на метр. Достаточно, чтобы видеть характерные детали вроде цвета одежды и считать людей.
• Распознавание – 125 пикселей на метр. Достаточно, чтобы понять, тот ли это человек, которого вы видели раньше.
• Идентификация – 250 пикселей на метр. Достаточно, чтобы опознать незнакомца по записи, – уровень доказательства в суде.

Модель построена на лицах: идентификация предполагает примерно 40 пикселей на ширину лица в 16 см, что и даёт 250 px/m. Та же камера, которая идентифицирует лицо на 3 метрах, лишь обнаруживает человека на 30 метрах, потому что плотность пикселей падает с расстоянием. Именно поэтому у вопроса «сколько камер?» нет ответа, пока вы не сказали по каждой зоне, какой уровень DORI нужен и на каком расстоянии.

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

На практике вы обходите объект (или план этажа) зона за зоной и пишете по строке на зону: участок, расстояние, цель DORI и любые постоянные ограничения (низкий свет, широкое поле, быстрое движение). Эта короткая таблица и есть документ требований, и она ценнее любого спецлиста, потому что каждое последующее число восходит к ней. Оговорка про реализм: модель плотности пикселей – это ориентир, а не гарантия; направление света, качество оптики и сжатие сдвигают результат – поэтому относитесь к числу DORI как к нижней границе и оставляйте запас на плохие условия.

Шаг 2 – От требований к числу камер, а от числа камер к трудозатратам

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

Число важно не только для железа, потому что трудозатраты растут с числом камер, но не всегда линейно. Бо́льшая часть труда в проекте – на каждую камеру: крепёж, прокладка кабеля, сетевой ввод, наведение, фокусировка и добавление камеры в ПО. Отраслевые цифры монтажа группируются около двух-четырёх часов квалифицированного труда на проводную коммерческую камеру – до нелинейных надбавок: подъёмник для высоких креплений, кабель-канал в бетоне, траншея к удалённой опоре, согласование с другими подрядчиками. Именно эти надбавки разводят два объекта с одинаковым числом камер в цене вдвое.

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

Таблица 1. Размерные диапазоны как ориентир. Суть не в точных часах, а в том, что́ определяет оценку, меняется с масштабом. В малом проекте число – это камеры и труд; в крупном число тихо становится хранилищем, сетью, услугами и управлением проектом.

Наш сквозной пример – в среднем диапазоне: объект на 60 камер (склад с торговлей) – 45 камер общего обзора уровня распознавания, 10 более узких камер на входах и в кассовой зоне для идентификации и 5 широких камер для двора. Запомните этот набор; множители из следующего раздела превращают его в хранилище и ПО.

Шаг 3 – Четыре множителя, которые двигают число

Число камер – это начало, а не ответ. Четыре множителя превращают число в те части оценки, которые удивляют людей. Сделайте их явными – и дальше только сложение.

Множитель 1 – Разрешение и частота кадров (а на деле – битрейт)

Разрешение и частота кадров влияют на оценку в основном через битрейт – мегабиты в секунду, которые выдаёт каждая камера и которые определяют и сетевую полосу, и хранилище. Современная камера 4 мегапикселя на эффективном кодеке H.265 выдаёт примерно 2–4 Mbps; камера 4K – примерно 4–10 Mbps в зависимости от движения. Кодек – реальный рычаг: H.265 обычно использует на 30–50% меньше битрейта, чем старый H.264, при той же картинке, так что выбор кодека в строке спецификации тихо меняет бюджет хранилища. (Сам кодек разобран в разделе про кодирование видео; здесь это просто множитель стоимости.)

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

Множитель 2 – Срок хранения (множитель хранилища, показанный вслух)

Срок хранения – сколько дней записи вы держите – это множитель, который чаще всего ломает бюджет, потому что хранилище – единственная статья, растущая ещё и со временем, а не только с числом камер. Это чистая арифметика, и её стоит один раз посчитать руками. Полезная константа: один непрерывный поток 1 Mbps даёт около 10,8 ГБ в сутки.

На камеру (непрерывно):  4 Mbps × 10,8 ГБ/сут на 1 Mbps = 43,2 ГБ/сут
Весь объект:             60 камер × 43,2 ГБ/сут          = 2592 ГБ/сут ≈ 2,59 ТБ/сут
Хранение 30 дней (полезн.): 2,59 ТБ/сут × 30 дней         ≈ 78 ТБ полезных

Эти 78 ТБ – это полезное видео. Реальному хранилищу нужно больше сырой ёмкости под резервирование: с RAID 6 плюс hot spare и накладными расходами файловой системы закладывайте примерно на 30% больше сырого диска – около 100 ТБ сырых для этого объекта. Полный метод хранения, включая тиринг старой записи на более дешёвый диск, разобран в хранении и расчёте ретенции; здесь суть в том, что срок хранения – это ползунок с крутым градиентом стоимости.

Этот градиент – и самое лёгкое место сэкономить, через режим записи. Непрерывная запись пишет всё; запись по движению или по событию пишет только когда что-то происходит, и на типичном объекте срезает хранилище на 40–60%, потому что бо́льшая часть часов пуста. Если перевести наш пример на запись по движению, 78 ТБ полезных падают примерно до 40 ТБ. Выбор режима записи – это решение оценки, а не только настройки; режимы сравниваются в стратегиях записи: непрерывная, по движению, по событию. Два правила держат срок хранения честным: правовые или эксплуатационные минимумы задают нижнюю границу (сколько вы обязаны хранить), а для систем, которые пишут опознаваемых людей в регулируемых регионах, закон о приватности задаёт верхнюю границу (сколько вы вправе хранить). Оценивайте по нижней границе и никогда не превышайте верхнюю.

Множитель 3 – Аналитика (вычисления, лицензии и юридический барьер)

Автоматически обнаруживать что-то в видео – считать людей, читать номера, отмечать человека в запретной зоне – добавляет три разных затраты, и путать их – классическая ошибка оценки. Есть вычисления (аналитика должна где-то работать – на чипе самой камеры на краю, на сервере или в облаке), есть лицензия (многие аналитики продаются за камеру или за поток) и есть настройка (кто-то должен задать зоны и пороги и снизить ложные срабатывания – строка труда, см. услуги ниже). Где работает аналитика, меняет её стоимость и задержку – это и есть тема аналитики на краю против облака; внутренности моделей принадлежат разделу AI for Video Engineering, а не оценке.

Две оговорки должны быть в каждой оценке аналитики. Первая: точность – это диапазон, а не число: детектор, заявленный в брошюре как «99%», работает с precision/recall, которые зависят от света, ракурса и сцены, так что закладывайте время на настройку и никогда не считайте от идеальной цифры. Вторая: некоторые аналитики – это юридический барьер прежде, чем строка сметы. Распознавание лиц и, во многих местах, распознавание автономеров обрабатывают биометрические или персональные данные, которые сильно ограничены: по GDPR ЕС это особая категория данных (ст. 9), а закон о биометрии штата Иллинойс (BIPA, 740 ILCS 14) даёт частный иск и установленные законом штрафы за неверно оформленное согласие. Следствие для оценки конкретно: биометрическая аналитика может добавить юридическую проверку, инфраструктуру согласия и процессы удаления, которые затмят стоимость её лицензии, – так что отмечайте её как барьер и считайте комплаенс, а не только ПО. Юридические детали – в GDPR для видеонаблюдения и BIPA и биометрических законах США.

Множитель 4 – Модель развёртывания (CapEx on-prem против OpEx cloud)

Последний множитель меняет форму всей оценки, а не одной строки: где живёт система. Сборка on-prem (локальная) – это в основном капитальные затраты: вы один раз покупаете камеры, серверы, хранилище и бессрочное ПО и эксплуатируете их. Сборка cloud / video-surveillance-as-a-service (VSaaS) – это в основном операционные затраты: легче вход, затем повторяющаяся плата за камеру, включающая хранилище и ПО. Готовое ПО VMS стоит примерно 50–300 $ за камеру-канал как разовая лицензия; VSaaS – примерно 10–50 $ за камеру в месяц. Эти два пути пересекаются: облако дешевле на старте и дороже в удержании, и точка пересечения обычно лежит где-то около второго-третьего года. На какой стороне пересечения вы хотите быть, зависит от горизонта, денег и ИТ-ресурсов – этот компромисс разобран в on-prem, cloud и гибридной VMS, а модель за обоими числами – в модели стоимости видеонаблюдения. Для обзора рынка, как платформы VMS упаковывают эти модели, см. руководство по системам управления видеонаблюдением – это коммерческое дополнение к данному инженерному взгляду.

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

Шаг 4 – Соберите стек затрат: объект на 60 камер от и до

Теперь сложите. Оценка – это стек строк, и дисциплина в том, чтобы включить каждый слой, особенно те, что не железо. Таблица ниже считает наш сквозной пример на 60 камер как локальную (on-prem) сборку. Диапазоны на камеру – иллюстративные плановые цифры 2026 года из публичных данных по монтажу и ПО, а не смета; столбец примера показывает одну разумную точку внутри этих диапазонов.

Таблица 2. Стек затрат для проработанного объекта на 60 камер (локальная сборка, иллюстративно). Обратите внимание на нижнюю строку: полная корпоративная сборка выходит около 2650 $ на камеру – заметно выше цифры «700–1500 $ на камеру», которую называют потребительские руководства, потому что та цифра считает только камеру и её монтаж и опускает серверы, хранилище, ПО, аналитику и услуги, которые нужны реальной системе. Оценить только строку камер – самый частый способ занизить смету.

Два момента в этой таблице стоит подчеркнуть. Профессиональные услуги – самый большой одиночный слой, а не камеры: проект, монтаж, пусконаладка и управление проектом регулярно составляют 40–70% стоимости коммерческого проекта. И резерв – это строка, а не извинение: названный буфер 10–15% на неизвестные (стена, которая оказалась бетонной, сорванный срок поставки) – признак зрелой оценки, а не раздутой.

Тот же объект как сборка cloud / VSaaS выглядит иначе по форме. Камеры, сеть и монтаж всё ещё капитальные (скажем, ~55 000 $ авансом), но серверы, хранилище и лицензии VMS заменяются подпиской: 60 камер × ~30 $/камеру/мес ≈ 1800 $/мес ≈ 21 600 $/год. За пять лет одна подписка – около 108 000 $, так что облачная сборка дешевле на старте и, за точкой пересечения, дороже в удержании – ровно тот компромисс, что предсказал множитель развёртывания. Прогоните оба с вашим реальным горизонтом в модели стоимости видеонаблюдения, прежде чем брать на себя обязательства.

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

Шаг 5 – Реалистичный график и хвост, который все недооценивают

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

• Проект и требования (2–4 недели). Обход объекта, строки DORI, фиксация набора камер, схема сети и хранилища, согласование срока хранения и аналитики. Здесь и происходит Шаг 1; пропуск просто переносит затраты на потом.
• Закупка и сроки поставки (4–10 недель, внахлёст). Заказываются камеры, серверы и коммутаторы. У корпоративной техники могут быть многонедельные сроки, и одна модель камеры в backorder способна затормозить фазу, так что заказывайте рано и параллельно с подготовкой объекта.
• Монтаж и кабели (2–6 недель). Крепёж, прокладка кабеля, вводы, питание и физическая сеть. Растёт с числом камер и с нелинейными надбавками (подъёмники, кабель-каналы, траншеи) из Шага 2.
• Пусконаладка и настройка аналитики (2–6 недель). Навести и сфокусировать каждую камеру, проверить, что каждая достигает своей цели DORI, задать режимы записи и срок хранения и – недооценённый хвост – настроить аналитику, пока ложные срабатывания не станут терпимыми. Настройка аналитики итеративна и зависит от сцены; это фаза, которую чаще всего урезают, и та, чьё отсутствие делает «сданную» систему бесполезной.
• Сдача и документы (около 1 недели). Исполнительная документация, доступы, обучение операторов и план обслуживания.

Для нашего объекта на 60 камер эти фазы накладываются примерно в три-пять месяцев проекта, где правят не монтаж, а срок поставки в начале и настройка в конце. Самая частая ошибка планирования – спланировать монтаж и забыть, что систему нужно пусконаладить: разрыв между «все камеры повешены» и «система делает свою работу» измеряется неделями, а не днями.

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

«Частые ошибки, которые рушат оценку видеонаблюдения. Оценка от бюджета (выбрать число, затем урезать охват под него). Считать камеры, но забыть хранилище (строку, которая растёт со сроком хранения, а не только с числом). Называть цифру монтажа «X $ за камеру» как весь проект (она опускает серверы, хранилище, ПО и услуги). Считать точность аналитики бесплатной и идеальной (ей нужно время на настройку, и это диапазон). Игнорировать сроки поставки и пусконаладку (две фазы, что решают дату запуска). Считать биометрическую аналитику лицензией, когда это юридический барьер. Каждая из них делает число меньше, чем проект.»

Оценка – это диапазон, а не число

Последняя дисциплина – выдать оценку как диапазон с названными допущениями, а не как одну уверенную цифру. Это делают три привычки. Ведите реестр допущений – дни хранения, режим записи, уровни DORI, ставку труда, модель развёртывания, – чтобы любой видел, что изменит цену. Закладывайте резерв под неопределённость проекта (10% для знакомого объекта, 15–20% для незнакомого). И назовите один-два решающих фактора, которые правят разбросом, – обычно срок хранения и аналитика, иногда доступ на объект, – потому что читатель, знающий решающие факторы, может делать выбор, а не спорить с итогом. Построенная так оценка не менее точна оттого, что она диапазон; она полезнее, потому что говорит читателю, где на самом деле деньги.

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

Оценка системы видеонаблюдения – это место, где инженерный взгляд Фора Софт оправдывает себя, потому что мы оцениваем так же, как строим: от задачи, которую решает каждая камера, с возвращёнными затратами, которые опускают демонстрации. Мы строим видеостриминг, видеонаблюдение и системы компьютерного зрения с 2005 года – более 250 проектов для более чем 400 клиентов, – и этот опыт проявляется в неброских строках: хранилище под реальный срок и режим записи, аналитика как диапазон precision/recall с заложенным временем настройки и профессиональные услуги, оценённые как крупнейший слой, которым они обычно и являются. Когда проекту нужна кастомная аналитика или интеграция VMS под конкретный объект, мы оцениваем её по тому, как она ведёт себя под нагрузкой – реальная точность, хранилище, которое не забивается раньше срока, держащаяся задержка, – а не по чистой демонстрации. Это и есть разница между оценкой, которая переживёт встречу с монтажом, и той, что не переживёт.

Главные выводы

• Стройте оценку снизу – от задачи каждой камеры, а не сверху от бюджета – и держите её как модель, которую любой может пересчитать.
• Шкалой DORI (IEC 62676-4) переводите цель каждой зоны в цель по пикселям; это решение задаёт число камер и бо́льшую часть стоимости.
• Хранилище – это арифметика: битрейт × камеры × часы × дни хранения. Режим записи и срок хранения – самые крутые рычаги стоимости.
• Четыре множителя двигают число – разрешение, срок хранения, аналитика и модель развёртывания (on-prem CapEx против cloud OpEx).
• Профессиональные услуги, а не камеры, обычно крупнейший слой; резерв – это строка, а не подушка.
• Планируйте хвост графика – сроки поставки и пусконаладку/настройку, – потому что эти две фазы решают дату запуска.

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

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