Отраслевое ПО

Разработка ПО для видеонаблюдения и видеоаналитики

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

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

Когда готового ПО для видеонаблюдения недостаточно

Коробочные VMS — Trassir, Macroscop, Ivideon и им подобные — решают базовый набор задач надёжно и без разработки: запись, архив, детекция движения, простое распознавание номеров или лиц по своей закрытой логике. Для офиса, склада или магазина среднего размера этого обычно хватает.

Заказная разработка нужна, когда возникает хотя бы одно из трёх:

• Нестандартная логика аналитики. Вендорская детекция работает по своим правилам — если нужно считать не просто «человек в кадре», а «человек без каски в зоне производства дольше 10 секунд», под это придётся дообучать или писать модель самим.
• Интеграция с бизнес-системами. Готовые VMS хранят события у себя. Если событие с камеры должно менять состояние в 1С, CRM или открывать доступ в СКУД — нужен слой, который это связывает, а такого слоя в коробочном продукте обычно просто нет.
• Экономика на масштабе. Большинство коммерческих VMS лицензируются поканально. При 100+ камерах и растущей аналитической нагрузке стоимость лицензий на длинной дистанции может обогнать разработку своей системы.

Из чего состоит система: протоколы и архитектура

Почти все современные IP-камеры говорят на одном языке — стандарте ONVIF: он используется для обнаружения камеры в сети, управления (поворот, зум, фокус) и получения параметров потока. Сам видеопоток при этом чаще всего идёт отдельно, по протоколу RTSP. Это разделение — управление через ONVIF, поток через RTSP — определяет, как строится архитектура: система сначала опрашивает камеры и получает список доступных потоков, а затем подписывается на нужные.

Дальше поток нужно куда-то деть. Три слоя, через которые обычно проходит видео:

1. Приём и хранение — запись на NVR или в объектное хранилище, с ротацией по времени или по срабатыванию события.
2. Аналитика — обработка кадров моделями детекции: людей, объектов, лиц, номеров, действий.
3. Шина событий — то, что превращает «модель что-то распознала» в «система что-то сделала»: отправила webhook, записала в базу, дёрнула API другого сервиса.

Ключевое архитектурное решение — где именно считается аналитика: на edge или на сервере.

Edge-аналитика

Обработка происходит прямо на камере или на локальном устройстве рядом с ней (промышленный мини-компьютер, специализированный NVR с NPU). Плюсы — низкая задержка и почти нулевая нагрузка на сеть, потому что наружу уходит не видео, а уже готовое событие. Минус — ограниченная вычислительная мощность: тяжёлые модели (точное распознавание лиц в толпе, сложная классификация) на edge-устройстве обычно не помещаются.

Серверная аналитика

Видео стримится на сервер с GPU, где крутятся более тяжёлые модели. Гибче, точнее, проще обновлять модели централизованно — но требует полосы пропускания под постоянный видеопоток с каждой камеры и инфраструктуры под это.

На практике почти всегда получается гибрид: лёгкая детекция «есть ли вообще движение или человек в кадре» — на edge, а тяжёлая классификация (распознать конкретное лицо, прочитать номер) запускается на сервере и только по триггеру от edge-слоя. Это экономит и полосу, и вычисления.

Видеоаналитика: какие модули реально нужны бизнесу

За вывеской «видеоаналитика» обычно скрывается один-два конкретных модуля, а не «искусственный интеллект вообще». Самые частые запросы:

• Подсчёт людей и трафика — вход/выход в ритейле, загрузка парковки, посещаемость зон.
• Распознавание номеров (LPR) — въезд/выезд на парковку или логистический двор без шлагбаумной карты.
• Распознавание лиц — проходная без пропуска, чёрные списки, VIP-оповещения на входе.
• Детекция средств защиты — каска, жилет, перчатки на производстве или стройплощадке — под требования охраны труда.
• Оставленные предметы и посторонние объекты — типично для банков, вокзалов, объектов с повышенными требованиями к безопасности.
• Тепловые карты и маршруты движения — для ритейла и планировки пространства.

Распознавание лиц и номеров — это уже не просто «картинка», а обработка персональных данных, и здесь стоит сразу закладывать требования 152-ФЗ в архитектуру, а не пристёгивать их постфактум.

Интеграция с бизнес-системами: СКУД, ERP, 1С

Смысл заказной разработки чаще всего именно здесь. Событие с камеры само по себе ничего не стоит бизнесу — ценность появляется, когда оно меняет состояние в другой системе:

• Распознанное лицо → команда в СКУД на открытие турникета, без физического пропуска.
• Человек в зоне склада без соответствующего доступа → событие в ERP, блокировка операции отгрузки до проверки.
• Подсчитанный трафик магазина → запись в аналитическую базу, сопоставление с данными продаж из 1С по часам.

Технически это делается через событийную архитектуру: аналитический сервис публикует событие (обычно через webhook или очередь сообщений), а бизнес-система на него подписывается и реагирует. Важно закладывать идемпотентность и очередь с повторной доставкой — камеры и сеть не идеальны, событие может продублироваться или не дойти с первого раза, и бизнес-логика должна быть к этому готова.

Готовое или заказное: как понять, что нужно вам

Сроки и стоимость

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

Мы не называем вилку цен заранее вслепую — на первом созвоне (обычно 40 минут) разбираем ваш процесс и через день присылаем предложение с конкретной фикс-ценой и сроком, а не диапазон «от».

Как выбрать подрядчика

Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:

• Просят показать архитектуру, а не только UI. Красивый интерфейс ничего не говорит о том, как система поведёт себя при потере связи с камерой или всплеске нагрузки.
• Отдельно проговаривают 152-ФЗ, если речь о лицах — если этот вопрос не задают сами, задайте его вы.
• Предлагают начать с одного сценария на части камер, а не сразу с проекта на всю систему — так ошибки в логике аналитики стоят недели, а не месяцы.
• Дают доступ к процессу, а не отчитываются раз в две недели письмом.