ONVIF: события, метаданные и аналитика

Коротко

Камера видеонаблюдения, которая что-то обнаружила, должна сообщить об этом программе записи понятным ей способом, и ONVIF определяет для этого два канала: канал событий, который говорит «что-то произошло», и канал метаданных, который описывает «вот что сейчас в сцене». События идут через сервис событий ONVIF – либо камера их отправляет (push), либо VMS их забирает (pull) – на базе открытого стандарта WS-BaseNotification, организованные по топикам, чтобы клиент подписывался только на нужное. Метаданные идут как структурированное XML-описание сцены (scene description) – рамки объектов, их позиции и классы – потоком рядом с видео по RTP, а Profile M – это профиль ONVIF, который связывает настройку аналитики, метаданные и события так, чтобы камера одного производителя и VMS другого договорились, как выглядит детекция. Стандарт гарантирует формат и «трубы», но не точность детекции и не переносимость правил – и именно это различие здесь главное.

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

Если ваша система видеонаблюдения когда-нибудь будет делать больше, чем просто запись – сигналить о пересечении линии человеком, считать посетителей, читать номера или давать оператору искать по полугоду записи «каждую машину у разгрузочной зоны», – то интерфейс событий и метаданных и есть тот шов, где этот «интеллект» либо проходит чисто, либо рассыпается. Эта статья для продакт-менеджера, интегратора или руководителя по безопасности, которому нужно подобрать связку «камера + VMS», которая реально разговаривает, и объяснить инженерам, почему бейдж «Profile M compliant» в даташите – это не та функция, что вам нужна. Код разбора вы писать не будете, но поймёте, что именно выдаёт аналитика, как это доходит до VMS, и четыре предсказуемых способа, которыми связь ломается. Сделаете правильно – аналитика станет искомой, тревожимой и переносимой между вендорами; ошибётесь – получите камеру, которая «обнаруживает» то, что внизу по потоку никто не видит.

Идут две разные вещи: события и метаданные

Начнём с разделения двух слов, которые путают, потому что это две разные задачи.

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

Метаданные – это непрерывное описание того, что в сцене: для каждого кадра список объектов, которые камера отслеживает, где их рамки и какого класса каждый. Это бегущий комментарий, а не одиночный сигнал.

Они связаны – событие часто и есть решение аналитики камеры, что метаданные пересекли какое-то правило («объект вошёл в зону»), – но идут по разным каналам, и VMS потребляет их по-разному. События ведут к тревогам; метаданные ведут к поиску и оверлею. Программе, которая принимает, записывает и управляет множеством потоков камер – Video Management System, или VMS – нужны оба. Статья предполагает, что вы примерно знаете, что такое ONVIF (открытый стандарт, позволяющий камерам и софту разных производителей работать вместе); если нет – начните с ONVIF для инженеров, а коммерческий обзор Фора Софт – профили ONVIF в системах безопасности.

События ONVIF: как камера говорит «что-то произошло»

Когда камера генерирует событие, она не придумывает свой формат. События ONVIF едут на паре открытых веб-сервисных стандартов OASIS – WS-BaseNotification 1.3 и WS-Topics 1.3, оба стандарты OASIS с 1 октября 2006 года – которые задают шаблон публикации/подписки по топикам: производитель (камера) выдаёт уведомления на именованных топиках, а потребитель (VMS) подписывается на нужные.

Каждое событие ONVIF несёт топик из дерева, записанный с префиксом пространства имён. Несколько настоящих:

• tns1:VideoSource/MotionAlarm – базовое движение, с состоянием, истинным, пока движение идёт.
• tns1:RuleEngine/CellMotionDetector/Motion – движение по сетке из rule engine.
• tns1:RuleEngine/FieldDetector/ObjectsInside – объект внутри заданной вами зоны.
• tns1:RuleEngine/LineDetector/Crossed – объект пересёк линию.

Топик – это фильтр. VMS, которой важны только пересечения линии, подписывается на эту ветку дерева и не разгребает каждый сигнал о движении. Одно уведомление, упрощённо, выглядит так – обратите внимание на очевидно вымышленные токены:

<wsnt:NotificationMessage>
  <wsnt:Topic>tns1:RuleEngine/FieldDetector/ObjectsInside</wsnt:Topic>
  <wsnt:Message>
    <tt:Message UtcTime="2026-06-08T09:14:02Z" PropertyOperation="Changed">
      <tt:Source>
        <tt:SimpleItem Name="VideoSourceConfigurationToken" Value="vsc-0"/>
        <tt:SimpleItem Name="Rule" Value="LoadingDockZone"/>
      </tt:Source>
      <tt:Data>
        <tt:SimpleItem Name="IsInside" Value="true"/>
      </tt:Data>
    </tt:Message>
  </wsnt:Message>
</wsnt:NotificationMessage>

Атрибут PropertyOperation заслуживает одного предложения внимания, потому что кодирует тонкость, на которой спотыкаются интеграторы. Некоторые события – это состояния-свойства: MotionAlarm либо включён, либо нет, и камера сообщает Initialized, затем Changed при переключении, а текущее состояние можно запросить – тогда как другие одноразовые. Клиент, который трактует событие «включено» у свойства как одноразовый импульс, получит тревогу, но никогда не узнает, когда она снялась – так индикатор движения навсегда «залипает» в плохой интеграции.

Pull или push: два способа, которыми событие доходит до VMS

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

Pull (PullPoint). VMS создаёт pull-point-подписку и затем повторно вызывает PullMessages, чтобы забрать события, накопившиеся с прошлого раза. Камере не нужно открывать соединение обратно к VMS; всю работу по «дотягиванию» делает VMS. Это вариант, дружелюбный к файрволам – камера сидит за своей сетью, ничего не говорит без спроса, а VMS стучится по расписанию.

Push (Base Notification). VMS подписывается один раз, и с этого момента камера отправляет сообщение Notify в VMS в момент срабатывания события, периодически продлевая подписку. Это ниже по задержке – без паузы на опрос – но требует, чтобы камера могла открыть соединение к VMS, что бывает проблемой через некоторые границы сети.

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

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

Метаданные ONVIF: описание сцены

События говорят, что произошло. Метаданные говорят, что камера видит, непрерывно, чтобы VMS рисовала рамки на «живом» виде и – куда ценнее – делала месяцы записи искомыми.

Формат – это scene description ONVIF, XML-структура из спецификации ONVIF Analytics Service. Представьте, что камера описывает сцену кадр за кадром. Каждый tt:Frame несёт объекты в этот момент; у каждого tt:Object есть id трекинга и форма:

<tt:Frame UtcTime="2026-06-08T09:14:02.500Z">
  <tt:Object ObjectId="42">
    <tt:Appearance>
      <tt:Shape>
        <tt:BoundingBox left="0.12" top="0.34" right="0.28" bottom="0.71"/>
        <tt:CenterOfGravity x="0.20" y="0.55"/>
      </tt:Shape>
      <tt:Class>
        <tt:Type Likelihood="0.92">Human</tt:Type>
      </tt:Class>
    </tt:Appearance>
  </tt:Object>
</tt:Frame>

Три поля делают основную работу. Bounding box – прямоугольник вокруг объекта, в нормализованных координатах, чтобы ложиться на любой размер экрана. Center of gravity – одна точка позиции объекта, удобная для трекинга и тепловых карт. Object id – идентификатор отслеживания, стабильный в пределах сессии – и здесь стоит сказать прямо: этот id сбрасывается при перезагрузке камеры, а повторно опознать того же человека на двух разных камерах – отдельная, более сложная задача, которую метаданные ONVIF не решают. Это работа модели аналитики, описанная в разделе ИИ для видеоинженерии и в статье этого раздела трекинг объектов и реидентификация – линкуйте, а не ждите, что метаданные камеры сделают это бесплатно.

Этот XML не едет по веб-сервисному вызову, как события. Он передаётся как трек метаданных внутри той же RTP-доставки, что несёт видео, с именем кодирования VND.ONVIF.METADATA (можно встретить как application/vnd.onvif.metadata, обычно на динамическом payload type 96). Иначе говоря, камера открывает одну RTSP-сессию, а VMS тянет из неё видео и параллельный поток метаданных. Механика транспорта – RTSP как пульт, RTP как несущая медиа – ровно та, что описана в статье RTSP, RTP и как видео наблюдения движется по сети; метаданные просто едут по тем же рельсам вторым треком.

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

Интерфейс аналитики: настройка того, что камера ищет

Пока что камера выдаёт события и метаданные. Но кто решает, что она обнаруживает, и как VMS это настраивает без софта производителя камеры? Это работа Analytics Service ONVIF – фреймворка настройки, а не фиксированной функции.

Через интерфейс аналитики клиент спрашивает камеру, какие модули аналитики она запускает (движение, саботаж, детекция объектов, пересечение линии, праздношатание, подсчёт людей, распознавание номеров или лиц), читает текущую конфигурацию каждого модуля и может добавлять, удалять или менять их. Сверху сидит rule engine: правила вроде «сработать, когда объект входит в этот полигон» или «считать объекты, пересекающие линию» – это и есть то, что превращает сырые детекции в события из прошлого раздела. Настройте FieldDetector с зоной – и камера начнёт выдавать события ObjectsInside на топике этой зоны.

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

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

Profile M: профиль, который всё связывает

Камера может говорить на событиях и метаданных ONVIF на множестве уровней полноты, поэтому ONVIF собирает возможности метаданных и аналитики в именованный профиль соответствия: Profile M («метаданные и события для приложений аналитики»), впервые опубликован в 2021 году, текущая спецификация – версия 1.1 (апрель 2024). Profile M – это ответ на вопрос «какая камера и какая VMS гарантированно договорятся об аналитике?».

Согласно спецификации Profile M, соответствующий продукт покрывает: настройку аналитики и запрос метаданных; конфигурацию и стриминг метаданных; общую классификацию объектов; определения метаданных для геолокации, транспортного средства, автомобильного номера, лица и тела человека; интерфейсы событий для подсчёта объектов и аналитики распознавания лиц и номеров; отправку событий через поток метаданных, сервис событий ONVIF или по MQTT; и конфигурацию правил. Profile M-устройство может быть edge-камерой или облачным сервисом аналитики; Profile M-клиент может быть VMS, NVR или облачным сервисом. Profile M ложится поверх профиля стриминга – его сочетают с Profile S или Profile T, чтобы одна камера отдавала и пиксели, и смысл.

Две вещи в Profile M решают, действительно ли он решает вашу задачу, и обе легко упустить:

Обязательное против опционального. Поток метаданных и сервис аналитики обязательны для соответствия; привязка событий через MQTT, rule engine, геолокация и богатые атрибуты лица/номера – опциональны. Камера может носить бейдж Profile M и всё равно не выдавать текст номера и не говорить по MQTT. Бейдж говорит «прошла тест на соответствие»; Declaration of Conformance (документ на каждый продукт на сайте ONVIF) говорит, какие опциональные функции эта конкретная прошивка реально реализует. Читайте Declaration of Conformance, а не маркетинговый лист – мы разворачиваем это в коммерческом спутнике ONVIF Profile M в 2026.

Мост MQTT. Опционально Profile M позволяет камере публиковать события как JSON по MQTT – лёгкому протоколу обмена сообщениями, на котором говорят брокеры Интернета вещей (IoT). Это превращает камеру в полноценное IoT-устройство: одна детекция может разойтись веером в VMS, в дашборд ритейл-аналитики и в систему автоматизации здания сразу, и ни одному из них не нужно знать марку камеры. Это мощно – и это та часть, которой чаще всего нет на конкретном экземпляре.

Покажем математику: реальная цена – индексация, а не трафик

Частый сюрприз – где ложится нагрузка. Метаданные дёшево гнать и дорого делать искомыми. Пройдём арифметику.

Кадр scene description на горстку объектов – это несколько килобайт XML. Гоните его, скажем, на 10 кадрах метаданных в секунду – и получите примерно:

Трафик метаданных:  3 КБ/кадр × 10 кадров/с × 8 бит = ~240 кбит/с на камеру
Сравните с видео:   поток H.265 4 МП                = ~4000 кбит/с на камеру

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

Поток событий:  50 камер × 20 событий/с = 1000 событий/с разобрать, маршрутизировать и индексировать
За сутки:       1000 × 86 400            = ~86 млн событий хранить и держать искомыми

Это и есть число, которое решает, вернётся ли судебный поиск за секунду или за минуту. Рычаг – не трафик, а чувствительность и фильтрация: поднимите порог уверенности, агрегируйте по id объекта на источнике и подписывайтесь только на нужные топики, иначе индекс утонет. Чувствительность детекции – это шкала «точность против полноты» (precision/recall), задаваемая моделью аналитики, никогда не единое число «точности»; честный разбор – в статье настройка аналитики: ложные тревоги и точность.

Как это всплывает в VMS

Сведём каналы вместе: аналитика камеры выдаёт метаданные (бегущее описание сцены) и события (срабатывания правил). Метаданные едут по RTP, и VMS накладывает их на «живое» видео и, если так настроена, архивирует как искомый индекс. События приходят через сервис событий ONVIF (pull или push) или MQTT, и VMS превращает их в тревоги, закладки и записи, по которым вы потом ищете.

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

Это та машинерия, что стоит за поиском по событию: как сделать месяцы записи находимыми – «покажи каждого Human в зоне разгрузки вечером прошлого вторника» – это запрос к архивированным метаданным ONVIF, ничего экзотичнее. А весь мультивендорный парк, где события и метаданные каждой камеры сведены в одну искомую систему, – это пункт назначения мультивендорного референс-паттерна. События и метаданные – это ещё и то, что подключение (прошлая статья – обнаружение и подключение камер в масштабе) и существует, чтобы включить: камера полезна, только когда её события доходят до VMS.

Типичные ошибки, к которым склоняет этот интерфейс

Горстка ошибок повторяется почти на каждой интеграции аналитики, и назвать их – половина лечения.

Выбрасывание метаданных. Большинство VMS по умолчанию записывают видео и выбрасывают поток метаданных – и тогда через неделю судебный поиск бесполезен, потому что искать не по чему. Если поиск в объёме работ, настройте архивацию метаданных до запуска, а не после того, как следователь спросит «что было в той зоне в 02:14?».

Доверие несинхронизированным часам. ONVIF не заставляет синхронизировать время. Если часы камеры уходят от VMS даже на полсекунды, её метаданные выглядят принадлежащими другому кадру, и операторы начинают сомневаться во всей системе. Принудительно ставьте NTP по парку; пары сотен миллисекунд дрейфа хватает, чтобы ввести следствие в заблуждение.

Предположение, что метки классов совпадают. «Human» у одного вендора – это «Person» у другого и «Pedestrian» у третьего. Формат метаданных стандартен; словарь внутри – нет. Мультивендорной системе нужна таблица сопоставления классов, иначе «покажи всех людей» молча пропустит треть камер.

Допущение штормов событий. Дефолтная чувствительность в оживлённой сцене может выдавать десятки событий в секунду на камеру, забивая брокер и индекс (см. математику выше). Задайте пороги, агрегируйте на источнике и фильтруйте по топикам.

Чтение бейджа как списка функций. «Profile M compliant» не обещает MQTT, текст номера или геолокацию – они опциональны. Читайте Declaration of Conformance на ту прошивку, что отгрузите.

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

Мы строим слой, которому приходится потреблять реальные, разновендорные события и метаданные – а не демку с одной камерой. На практике это VMS, которая подписывается на события ONVIF через pull там, где сеть за файрволом, и через push там, где важна задержка, разбирает метаданные scene description в искомый индекс, сводит словарь классов каждого вендора в один и переживает момент шторма событий, а не плавится под ним. Наша установка – accuracy-vs-performance: мы измеряем, как пайплайн событий и метаданных ведёт себя при реальном числе камер и реальной частоте событий – где цена индексации и дрейф часов реально кусаются – прежде чем обещать интегратору чистый кросс-вендорный поиск. Видеонаблюдение и компьютерное зрение в центре того, что Фора Софт отгрузила за 250+ проектов с 2005 года, включая интеграции ONVIF и Profile M в ритейле, умном городе и промышленности.

Ключевые выводы

• События говорят «что-то произошло»; метаданные описывают «что в сцене». VMS нужны оба.
• События ONVIF едут на топиках WS-BaseNotification; камера шлёт (Notify) или VMS забирает (PullPoint).
• Метаданные – это XML-описание сцены (рамки и классы объектов), трек VND.ONVIF.METADATA по RTP.
• Analytics Service настраивает модули и правила; ONVIF стандартизирует выход, не точность и не формат правил.
• Profile M связывает аналитику, метаданные и события – но MQTT, правила и богатые атрибуты опциональны; читайте DoC.
• Реальная цена – индексация событий и архив метаданных, не трафик; задайте пороги и синхронизируйте часы.

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

• Профили ONVIF S, G, T и M – какой профиль нужен вашему продукту – где Profile M в системе профилей.
• Поиск по событию: как сделать месяцы записи находимыми – что открывают архивированные метаданные.
• Проприетарные SDK камер: когда ONVIF недостаточно – когда интерфейс аналитики заканчивается.