Для каждого уведомления заранее задаём:
- событие;
- зону;
- расписание;
- получателя;
- ожидаемое действие.
Событие
Не «уведомлять о движении вообще», а конкретно:
- человек вошёл в закрытую зону;
- автомобиль появился у ворот;
- пересечена линия;
- дверь открылась ночью;
- камера потеряла связь;
- очередь превысила порог.
Обычное обнаружение движения и классификация человека/автомобиля — разные возможности.
Зона
Чем точнее ROI соответствует реальному месту события, тем меньше лишних тревог.
Например:
- вход;
- ворота;
- складская дверь;
- участок периметра;
- касса.
Расписание
Одинаковое событие может быть нормальным днём и тревожным ночью.
Правила могут зависеть от:
- рабочего времени;
- выходных;
- смен;
- закрытия объекта.
Получатели
Не всем нужны все уведомления.
Разделяем:
- владельца;
- охрану;
- управляющего;
- технического администратора.
Технические события вроде «камера недоступна» лучше не смешивать с охранными тревогами.
Уведомление должно вести к контексту
Хорошее уведомление открывает:
- нужную камеру;
- нужный момент;
- архив, если платформа это поддерживает.
Пользователь не должен искать Camera 17 вручную.
Интернет
Локальная аналитика может продолжаться без WAN, но уведомление на внешний телефон обычно зависит от внешней связи и инфраструктуры сервиса.
Локальная запись и мобильное уведомление — разные функции.
Ложные тревоги
На пилоте проверяем:
- тени;
- дождь и снег;
- фары;
- ветки;
- животных;
- персонал;
- транспорт.
Не обещаем отсутствие ложных срабатываний без теста сцены.
Пропущенные события
Отдельно проверяем пропуск события:
- нужное событие произошло;
- уведомление не пришло;
- аналитика не распознала объект;
- телефон запретил уведомления;
- сеть задержала доставку.
Это не менее важно, чем лишние уведомления.
Настройка чувствительности
Максимальная чувствительность не всегда лучше.
Слишком высокая создаёт шум, слишком низкая пропускает события.
Если платформа поддерживает:
- минимальная длительность;
- подавление повторных срабатываний;
- фильтры объектов;
- расписания,
используем их по реальному сценарию.
Пилот
Сначала одна репрезентативная зона.
Фиксируем:
- правильные события;
- ложные;
- пропущенные;
- задержку;
- реакцию пользователя.
После этого масштабируем правила на другие камеры.
Приёмка
- создаём нужное событие;
- уведомление приходит нужному пользователю;
- открывается правильная камера;
- время совпадает;
- архив содержит эпизод;
- лишний сценарий не тревожит, если это требование;
- после перезапуска система работает так же.
Что прислать
- модель камеры/VMS;
- зону;
- нужное событие;
- расписание;
- получателя;
- телефон iOS/Android;
- примеры ложных тревог.
Частые вопросы
Можно получать уведомления только по человеку?
Если камера или VMS поддерживает классификацию.
Работает без интернета?
Локальное событие может определяться, но внешнее уведомление обычно требует WAN.
Можно разные уведомления разным людям?
Если платформа поддерживает пользователей и правила.
Почему слишком много уведомлений?
Нужно проверить тип события, ROI, расписание и чувствительность.
Это заменяет охранную сигнализацию?
Нет. Видеоаналитика и охранная сигнализация решают разные задачи.