ONVIF Profile M в 2026: стандарт метаданных, который упорядочивает мультивендорную видеоаналитику

Почему этот плейбук написала Фора Софт

Компания Фора Софт уже 20+ лет разрабатывает программное обеспечение для видеостриминга и видеонаблюдения. Из 250+ проектов те, что связаны с IP-камерами, VMS, нательными камерами, записью судебных заседаний и видеоаналитикой, объединяет одна и та же проблема — работа с метаданными. Со стримом всё понятно — RTSP, H.264, H.265, готово. А вот именно на метаданных мультивендорные интеграции и ломаются — и именно здесь должен помочь ONVIF Profile M.

В этом плейбуке мы собрали опыт внедрения Profile M и связанного с ним стека аналитики ONVIF в реальных проектах: что на самом деле требует спецификация, о чём умалчивают маркетологи производителей камер, как за пять минут проверить DoC, как подключить поток Profile M к VMS, изначально построенной на проприетарных SDK, и когда лучше отказаться от Profile M и использовать SDK вендора напрямую. Подробности о масштабах и отраслях, в которых мы работаем, — в наших услугах по видеонаблюдению и портфолио проектов.

Что на самом деле стандартизирует ONVIF Profile M

ONVIF Profile M — это профиль метаданных и аналитики, опубликованный Open Network Video Interface Forum в 2021 году. Если Profile S и Profile T отвечают за видеопоток, то Profile M описывает всё, что характеризует содержимое этого потока: детекции объектов, события, описание сцены и настройки аналитического модуля, который их генерирует. Подробный обзор остальных профилей (S, G, T, C, D, A) смотрите в нашей соседней статье об ONVIF-профилях в системах безопасности.

Если говорить конкретно, Profile M гарантирует на совместимых камерах, энкодерах и VMS-клиентах три вещи:

1. Обязательный поток метаданных. Ограничивающие прямоугольники объектов, центры тяжести, метки классов и простые атрибуты сериализуются в XML-описании сцены (ONVIF Scene Description) внутри RTP-payload. Любой клиент, поддерживающий профиль M, сможет обработать эти данные без использования проприетарных драйверов.

2. Стандартная модель событий. События детекции и правила поступают через сервис событий ONVIF (XML поверх SOAP, pull-point или базовые уведомления) и, при необходимости, через MQTT с JSON-данными — это позволяет использовать IoT-брокеры и облачную аналитику.

3. Настраиваемый аналитический сервис. Клиенты могут узнать, какие аналитические модули работают на устройстве (детекция движения, защита от вмешательства, пересечение линии, подсчёт людей, распознавание номеров, распознавание лиц), настроить их параметры и подписаться на события — и всё это без использования проприетарных инструментов прошивки.

Как Profile M связан с профилями S, T, C и G

Profile M никогда не заменяет профиль стриминга — он работает поверх него. Практически все современные камеры комбинируют Profile M с Profile T (расширенный стриминг, H.265, обработка событий), а зачастую — и с Profile G (локальное хранение). Если нужна проверка доступа по лицу или номеру, подключают Profile C. Простое правило: Profile S/T передаёт изображение, Profile M — смысл, Profile C — решения по доступу, Profile G — архивы.

Модель метаданных Profile M за 60 секунд

Каждое Profile M-устройство выдаёт Scene Description в виде дерева. Корень — это сцена (вид с камеры). Каждый обнаруженный объект — дочерний узел с набором обязательных и опциональных полей. Понимание этой структуры — самое выгодное вложение времени для инженера VMS: почти каждый баг интеграции возникает из-за неправильного прочтения одного из этих полей.

События, MQTT и мост в IoT

Profile M наследует сервис событий ONVIF (XML поверх SOAP, pull-point или базовое уведомление) и добавляет опциональную привязку к MQTT с JSON-полезной нагрузкой. Именно MQTT-мост интересен большинству проектов: он превращает камеру в полноценное IoT-устройство, которое может работать с любым брокером (HiveMQ, Mosquitto, AWS IoT Core, Azure IoT Hub, Google Cloud IoT).

Типовое развёртывание выглядит так

1. Камера (аналитика на edge). Обнаруживает объекты, применяет правила (пересечение линии, праздношатание, подсчёт) и публикует JSON-события в MQTT-топик вроде site/building-a/cam-17/events/line-crossing.

2. Брокер. Локальный Mosquitto для оповещений с минимальной задержкой или облачный брокер (AWS IoT Core) для сбора данных с нескольких площадок. TLS и клиентские сертификаты в продакшене обязательны.

3. Потребители. VMS подключается для визуального поиска и индексации архива. BI-сервис — для подсчёта посетителей в ритейле. Система контроля доступа — на триггеры LPR. Ни одной из этих систем не нужно знать, какой именно вендор камеры используется.

4. Защита от штормов событий. На камере установите порог уверенности не ниже 0,7, на издателе агрегируйте данные по ObjectId, а на стороне брокера применяйте фильтрацию топиков. Загруженная городская камера при стандартных настройках может генерировать 30–100 событий в секунду. Без батчинга такой поток за час может полностью заполнить облачный тариф брокера, что обойдётся в 3 750 ₽ в месяц.

Как прочитать Declaration of Conformance за пять минут

«Совместимо с Profile M» на странице с характеристиками — это маркетинговая фраза; настоящий документ — это DoC. У каждого сертифицированного по ONVIF продукта DoC доступен в PDF на странице onvif.org/conformant-products. В этом PDF перечислены все проверенные функции — обязательные и дополнительные — и напротив каждой стоит галочка, если она действительно работает в той прошивке и версии продукта, которую вы покупаете.

Чек-лист DoC из 8 пунктов

1. Версия прошивки. Сертификация выдаётся на конкретную сборку прошивки. Обновление может (и иногда действительно ломает) совместимость. Фиксируйте версию прошивки в спецификации оборудования при развёртывании.

2. Стриминг метаданных. Обязателен всегда. Проверьте шаблон URL потока и диапазон портов RTP.

3. Аналитический сервис. Обязателен всегда. Уточните WSDL-эндпоинт и список доступных аналитических модулей.

4. События по MQTT. Опционально. Если нужна интеграция с IoT, эту галочку обязательно нужно поставить. Проверьте настройки TLS, уровень QoS (1 или 2) и режим аутентификации.

5. Движок правил. Опционально. Пересечение линии, праздношатание, тейлгейтинг, подсчёт — всё это работает только при включённой галочке. Если галочка не стоит, камера передаёт сырые детекции, а правила вы настраиваете ниже по цепочке обработки.

6. Классы объектов. Опционально. Сопоставьте перечисленные классы с вашей канонической таксономией. Камера, поддерживающая только классы «Человек» и «Транспортное средство», не сможет предоставить метаданные распознавания номеров или лиц.

7. Геолокация. Опционально. Обычно зависит от калибровки PTZ или заранее заданных зон обзора.

8. Аутентификация. Digest обязателен; WS-Security и HTTPS — опциональны, но настоятельно рекомендуются. Любое устройство без HTTPS в развёртывании 2026 года — вне допустимого.

Кто реально выпускает Profile M в 2026 году

Profile M появился в 2021 году; внедрение идёт стабильно, но неравномерно. Enterprise-бренды камер перешли первыми; средний и бюджетный сегмент пока только догоняют. По нашим наблюдениям за парком клиентских развёртываний картина примерно такая:

Итог: в любом смешанном парке, где используются камеры Hikvision или Dahua, без проприетарного SDK хотя бы для части системы не обойтись. Подробнее о дорожной карте SoC, лежащей в основе этих различий, — в нашей статье о трендах IP-камер с ИИ.

Сколько людей или номеров реально может распознавать камера с Profile M?

Это самый частый вопрос покупателей — и он не имеет никакого отношения к Profile M. Profile M стандартизирует, как детекции передаются. Ёмкость определяют пять аппаратных и сценических факторов:

1. Разрешение сенсора и количество пикселей на цель

Для надёжного распознавания лица расстояние между глазами должно составлять около 80–120 пикселей. Для номера — 150–180 пикселей по ширине. Сенсор 4K (8 МП) с углом обзора 60° способен удерживать в поле зрения 3–5 лиц на расстоянии 10 метров; сенсор 2 МП при том же угле едва справляется с одним. Физике всё равно, какой протокол метаданных вы используете.

2. Мощность аналитического SoC

Axis ARTPEC-9, Ambarella CV25/CV52, процессоры Hikvision ACUSENSE и NVIDIA Jetson Orin Nano — все они используются в камерах с Profile M. Младшие SoC справляются с 20–40 одновременными детекциями, а старшие — с более чем 200. В спецификации DoC эта информация не указана — смотрите даташит на продукт или уточняйте у поставщика.

3. Частота кадров и движение

Машина на скорости 60 км/ч проезжает типичное поле зрения камеры меньше чем за секунду. При 15 кадрах в секунду номерной знак размазывается почти на всех кадрах; при 30–60 кадрах в секунду с быстрым электронным затвором уже получаются пригодные для распознавания номера кадры. Частота кадров и выдержка идут в обмен на чувствительность в условиях слабой освещённости — всё это указано в даташите производителя.

4. WDR, ИК и поведение при слабом освещении

Затенённые входы и дверные проёмы с подсветкой хуже всего влияют на распознавание лиц — хуже, чем любой некорректный код. Помогают камеры с WDR 120 дБ, starlight-сенсорами и ИК-подсветкой. Подробные рекомендации — в нашем разборе лучших практик обработки видео в реальном времени с использованием ИИ.

5. Порог уверенности

Каждый аналитический модуль можно настроить. Если снизить порог — ёмкость увеличится, но вместе с ней вырастут и ложные срабатывания, и нагрузка на MQTT. Для тепловых карт в ритейле мы обычно ставим 0,55; для контроля доступа — 0,85; для распознавания номера LPR — 0,80 после кросс-валидации.

Эталонная архитектура VMS, нативная для Profile M

Это шаблон, который мы используем, когда клиент просит Форс Софт построить VMS, нативно интегрированную с Profile M с самого начала. Он намеренно простой — вся сложность сосредоточена в адаптерах.

1. Edge-слой. Камеры Profile M (Axis, Bosch, Dallmeier) отправляют RTP-метаданные и MQTT-события. Для камер без поддержки Profile M (Hikvision, Dahua) запускаем лёгкий шлюз интеграции, который преобразует проприетарные SDK в формат JSON, совместимый с Profile M.

2. Брокер. Кластер Mosquitto на двух серверах Hetzner AX-52 для развёртываний в одном регионе; AWS IoT Core — для клиентов, работающих в нескольких регионах. Используется TLS 1.3 и клиентские сертификаты.

3. Хранилище метаданных. TimescaleDB (на базе PostgreSQL) используется для индексирования временных рядов событий; S3 / Backblaze B2 — для хранения XML-объектов ONVIF Scene Description, ключи — ID камеры и временная метка. Горячее хранение данных длится от 30 до 180 дней в зависимости от направления.

4. Ядро VMS. Stream manager (GStreamer + Janus) для видео; роутер событий для метаданных. Веб-клиент передаёт видео по WebRTC; метаданные — по WebSocket с наложением.

5. Аналитическая шина. Kafka или NATS внутри; ниже по потоку — сервис поиска, сервис оповещений и BI-каналы.

6. Клиенты. Веб, iOS, Android; подробности по мобильной части — в нашем материале об Android SDK для видеонаблюдения.

Пять продакшен-сценариев, которые реально открывает Profile M

Распознавание номеров на въезде

Profile M отдаёт объект LicensePlate с ограничивающим прямоугольником, текстом номера (опционально) и оценкой уверенности. Типичная схема — пара камер: одна снимает общий план, вторая использует оптику, настроенную под LPR. Чтение номеров мы обычно кросс-валидируем на отдельном ALPR-сервере, потому что опциональные поля с текстом номера не гарантируют точность OCR.

Контроль доступа в здание с распознаванием лиц

Profile M делает детекцию, а не распознавание лиц 1:N. Привычный сценарий: камера обнаруживает лицо и передаёт фрагмент через ONVIF или снапшот RTSP, сервис распознавания (свой или вендорский по NIST-FRVT) определяет личность, Profile C открывает дверь. Хранение базы шаблонов лиц вне камеры — выигрыш и по приватности, и по удобству поддержки.

Тепловые карты и аналитика очередей в ритейле

ObjectId + таймстампы + ограничивающие прямоугольники — этого достаточно для построения тепловых карт времени присутствия, анализа воронок «ряд за рядом» и графиков длины очередей. MQTT JSON легко интегрируется в BI-инструменты (Grafana, Looker). Подробнее — в нашем материале о видеоаналитике для ритейла.

Защита периметра и обнаружение вторжений

Правила пересечения линии и зональных вторжений в движке правил камеры публикуются как события Profile M и передаются в центральный сервис оповещений. В сочетании с классической AI-детекцией аномалий это покрывает 80% типовых сценариев на периметре.

Контроль промышленной безопасности

Детекция СИЗ (касок, светоотражающих жилетов, перчаток) всё чаще реализуется как аналитический модуль Profile M на индустриальных камерах. Мы внедряли его для заказчиков из строительной и нефтегазовой отраслей; подробности по машинному обучению — в наших разборах о детекции касок в видеонаблюдении и алгоритмах для выявления аномалий.

Мини-кейс — мультивендорный парк, один backplane на Profile M

Ситуация. Региональный интегратор физической безопасности обратился к нам с парком из 240 камер на трёх офисных кампусах: камеры Axis P-серии на периметре, Bosch Flexidome внутри помещений и устаревшая стойка из 60 камер Hikvision DS-серии, которые должны были отработать оставшуюся гарантию. Три разных SDK, три формата событий и команда мониторинга, готовая нанять двух новых операторов, чтобы справляться с дашбордами.

План на 10 недель. Недели 1–2: аудит DoC по каждой модели Axis и Bosch, разбор Hikvision (Profile M отсутствует). Недели 3–5: поддержка Profile M для Axis и Bosch, шлюз ISAPI→Profile M для стойки Hikvision. Недели 6–7: MQTT-брокер (кластер Mosquitto на Hetzner), хранилище метаданных на Timescale, API поиска. Недели 8–9: интеграция в консоль оператора, настройка NTP, правила оповещений. Неделя 10: приёмка, нагрузочное тестирование, подготовка runbooks.

Результат. Сквозная задержка оповещения снизилась с ~3,2 с до менее чем 900 мс, поисковые запросы по 30-дневным метаданным стали выполняться за менее чем 1 с по p95, а команда эксплуатации больше не поддерживает три отдельных вендорских плагина. Дополнительные операторы не потребовались. Похожие истории мультивендорных парков — в нашем материале об инженерных решениях для масштабируемой VMS.

Инструменты, которые делают Profile M рабочим на практике

ONVIF Device Manager. Бесплатная утилита для Windows — до сих пор самый быстрый способ проверить новую камеру. Покажет поток метаданных, аналитический сервис и топики событий без единой строчки кода.

gSOAP + onvif-sdk. Для потребителя на C/С++ в продакшене генерируйте WSDL-биндинги с помощью gSOAP; в Python обычно используют библиотеку onvif-zeep. Храните локальную копию WSDL — онлайн-разрешение DTD ненадёжно.

onvif2mqtt / onvif-mqtt. Открытые мосты, которые преобразуют XML-события ONVIF в JSON для MQTT. Подходят как пример реализации; обработку ошибок и аутентификацию нужно дорабатывать самостоятельно перед использованием в продакшене.

MQTT Explorer. Графический клиент MQTT для просмотра топиков и полезной нагрузки в реальном времени. Незаменим, когда отлаживаете ситуацию с потоком событий.

Conformance-инструменты ONVIF. Только для производителей, но если вы разрабатываете устройство — вам туда. Эталонные реализации ONVIF (например, Happytime ONVIF Server) полезны для тестовых стендов.

Wireshark + RTP-диссекторы. Когда XML описания сцены выглядит повреждённым, правду покажет RTP-полезная нагрузка. Держите под рукой инструкции по tcpdump.

Пять проблем интеграции, с которыми не справляется Profile M

1. Метаданные по умолчанию не архивируются. Большинство VMS-платформ записывают видео, но отбрасывают поток метаданных — и через неделю удивляются, почему поиск по событиям не работает. Настройте параллельное архивирование метаданных (обычно используем JSON-сайдкары и индекс в Timescale) ещё до запуска в продакшен.

2. Таксономии классов разнятся. Axis использует «Human», Hanwha — «Person», Bosch — «Pedestrian» — это одно и то же, но разные названия. Ведите таблицу соответствий и логируйте неизвестные классы: рано или поздно обновление прошивки тихо добавит новый.

3. Синхронизация времени подразумевается, а не предписывается. NTP в Profile M не обязателен. Дрейф в 900 мс между камерой и VMS приводит к тому, что метаданные оказываются привязаны к другому кадру — и следователи начинают сомневаться в достоверности системы. Внедряйте NTP с целевой точностью <100 мс и настройте оповещения при дрейфе >500 мс.

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

5. Движки правил невзаимозаменяемы. Правила пересечения линии, настроенные на камере Axis, не подойдут для Bosch — Profile M стандартизирует формат выходного события, но не описание правил. Конфигурацию создавайте в вендоронезависимой модели и конвертируйте её в API правил каждой конкретной камеры.

Сколько на самом деле стоит интеграция Profile M VMS

Это инженерные оценки, которые мы предоставляем клиентам до запуска. Цифры рассчитаны с учётом нашего workflow с ускорением через Agent Engineering; командам без ускорения закладывайте на 40–60% больше часов.

Типовые ценовые диапазоны на камеры, которые указаны в спецификациях: 30 000–60 000 ₽ за начальный уровень Profile M (базовая детекция, без MQTT), 67 500–135 000 ₽ за средний сегмент (распознавание лиц и номеров + MQTT), 150 000–300 000 ₽ и выше — за камеры с высоким разрешением, WDR, ИК-подсветкой и встроенным движком правил.

Рамка принятия решения — пять вопросов, после которых становится ясно, нужен ли Profile M

Q1. Будет ли парк камер мультивендорным? Если да, то Profile M обязателен. Если в ближайшее время вы будете использовать оборудование только одного вендора, нативный SDK обычно даёт больше возможностей и работает быстрее.

Q2. Будут ли один и тот же поток аналитики потреблять несколько систем? VMS + BI + контроль доступа + SCADA = Profile M + MQTT. Достаточно одной VMS — событий Profile M или даже проприетарных.

Q3. Гибкий ли набор функций нужен? Если требуется распознавание лиц, одного Profile M недостаточно — понадобится отдельный сервис распознавания. Если нужны только детекция и события, Profile M полностью покрывает задачу.

Q4. Есть ли в команде инженеры, которым удобно с SOAP / gSOAP / MQTT / RTP? Это не самый современный стек. Если команда работает только на JavaScript — закладывайте дополнительные часы на обучение.

Q5. Что происходит при обновлении прошивки? Если у вас строгий регламент change-control (что хорошо), проверка совместимости Profile M не вызывает сложностей. Если же прошивки обновляют выездные инженеры по мере необходимости (что бывает чаще), заранее подготовьте тестовый стенд, который перед развёртыванием перепроверит функции, указанные в DoC.

Три и более «да» — выбирайте Profile M. Меньше — оставайтесь на нативном подходе и пересмотрите решение при следующем обновлении парка.

Пять ловушек, в которых тонут проекты на Profile M

1. Воспринимать значок Profile M как список функций. Значок означает лишь, что мы прошли тест совместимости на конкретной прошивке. Он не гарантирует, что камера поддерживает OCR номеров, MQTT или геолокацию. Всегда читайте DoC.

2. Не задавать порог уверенности. Значения по умолчанию в загруженной сцене перегружают брокер, хранилище и интерфейс оповещений. Устанавливайте пороги для классов и отслеживайте частоту событий с самого начала.

3. Забыть про архив метаданных. Через полгода в продакшене SOC спрашивает: «Что было в зоне в 02:14 в прошлый вторник?» — и получает видео без оверлея метаданных. Архив проектируйте до запуска, а не после.

4. Отсутствие регламента NTP. Каждая камера и каждый сервер используют свою политику NTP — из-за этого часы сбиваются. Используйте единый источник времени stratum-1 и настройте оповещения при обнаружении дрейфа.

5. Нет плана для несовместимых камер. В любом реальном развёртывании из более чем 20 камер хотя бы одна окажется несовместимой или не соответствует спецификации. Заранее предусмотрите шлюзовой слой, чтобы потом не пришлось срочно дорабатывать систему.

KPI: что измерять на пайплайне Profile M

KPI качества. Recall не ниже 0,85 по целевым классам объектов; precision — не ниже 0,80; доля ошибочной классификации — не более 5%. Проверяйте ежеквартально на размеченных тестовых наборах для каждой площадки, а не один раз при сдаче.

Бизнес-метрики. Полное время оповещения (обнаружение камерой → консоль оператора) — менее 1 секунды; время поиска по метаданным за 30 дней — менее 2 секунд по p95; доля подтверждённых ложных срабатываний в SOC — менее 3%.

KPI надёжности. Доступность потока метаданных — не менее 99,5% на камеру в месяц; дрейф NTP — менее 100 мс по 99-му перцентилю; запас пропускной способности MQTT-брокера — не менее 30% от наблюдаемого пика.

Когда Profile M — не тот ответ

Profile M не бесплатен. Он добавляет сложность работы с WSDL, требует хранения архива метаданных, включает сервис сопоставления классов и создаёт дополнительную операционную нагрузку (например, соблюдение регламента DoC, настройка NTP). Пропустите его, когда:

Развёртывание на одном вендоре. Связка Milestone + Axis или Genetec + Hanwha позволяет использовать больше возможностей нативного драйвера. Profile M здесь — страховка на случай смены поставщика.

Проекты до 10 камер. Накладные расходы на обвязку Profile M не окупаются на небольших площадках. Оставайтесь на RTSP + событиях и одном аналитическом контейнере.

Потребительские или «облачные камеры». Если вы делаете продукт, где камера идёт в комплекте с облаком (как Ring или Nest), Profile M добавит избыточности, которой вы не воспользуетесь; проприетарный протокол окажется проще.

Оповещения с ультранизкой задержкой. Для оповещений с задержкой менее 100 мс (например, наблюдение в торговом зале биржи или контроль периметра критических объектов) прямой WebRTC с тревожными метаданными в потоке работает быстрее, чем путь через Profile M. Используйте Profile M для архивации и бизнес-аналитики, а не для передачи данных в реальном времени.

FAQ

«Совместимо с ONVIF» — это то же самое, что «совместимо с Profile M»?

Нет. Совместимость с ONVIF — это широкое понятие; она может означать Profile S (стриминг), G (хранение), T (расширенный стриминг), C (управление доступом), M (метаданные), D (управление дверями) или A (настройка параметров). Совместимость с Profile M — это конкретное подмножество, отвечающее за работу с метаданными и аналитикой. Камера может быть ONVIF-совместимой, даже если не прошла сертификацию по Profile M.

Требует ли Profile M Profile T или Profile S?

Сам Profile M профиля стриминга не требует, но на практике любая камера, которую вы реально купите, поставляется с Profile M вместе с Profile T или Profile S — чтобы клиент мог одним инструментом получать и видео, и метаданные. По спецификации ONVIF Profile M рассматривается как слой поверх того профиля стриминга, который реализует устройство.

Обязателен ли MQTT в Profile M?

Нет. MQTT — опциональная привязка для событий ONVIF в Profile M. Обязательный способ передачи событий — сервис событий ONVIF поверх SOAP. Перед тем как строить IoT-пайплайн на основе MQTT, проверьте поддержку в DoC.

Можно ли сделать распознавание лиц только средствами Profile M?

Только детекцию, а не распознавание 1:1. Profile M может содержать ограничивающий прямоугольник лица и, по желанию, непрозрачный дескриптор лица. Превратить это в сопоставление с личностью можно только с помощью отдельного сервиса распознавания и базы шаблонов. И, как правило, именно так и стоит делать — ради приватности и удобства поддержки.

Как узнать, поддерживает ли конкретная камера MQTT в рамках Profile M?

Скачайте Declaration of Conformance с onvif.org/conformant-products и найдите строку с интерфейсом событий MQTT. Если стоит галочка — камера прошла тест совместимости по MQTT; если нет — функция не гарантирована, даже если в рекламном листе значится «готова к IoT».

Гарантирует ли Profile M точность распознавания текста номера в LPR?

Нет. Атрибут с текстом номера — опциональный, и спецификация стандартизирует только перенос текста и значение уверенности, но не точность OCR. Качество OCR зависит от аналитического модуля камеры, разрешения, угла съёмки и освещения. Для продакшен-ALPR проводите независимую валидацию.

Моя VMS автоматически архивирует метаданные Profile M?

Большинство VMS — нет. Они записывают видео и иногда выделяют ключевые события, но полные метаданные Scene Description по умолчанию не сохраняют. Если в рамках расследования нужен форензик-поиск, подключайте отдельное хранилище для метаданных (мы используем TimescaleDB и S3-совместимое объектное хранилище для блобов Scene Description).

Сколько камер может обслуживать один Profile M-потребитель?

По нашему опыту, один процесс-потребитель на скромной виртуальной машине (4 vCPU, 8 ГБ RAM) справляется с 60–120 камерами при типичных частотах событий (менее 20 событий в секунду на камеру). Дальше распределяйте нагрузку по ObjectId между воркерами, а рассылку событий оставьте брокеру. Объём событий в профиле M линейно растёт с увеличением числа камер и порогов уверенности.

Обновление прошивки ломает совместимость с Profile M?

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

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

Готовы встроить Profile M в свой продукт?

ONVIF Profile M дал мультивендорным системам видеонаблюдения то, чего пришлось ждать почти десятилетие: общий язык для детекций и событий аналитики. Сам по себе значок — ещё не стратегия. Настоящая работа — правильно читать DoC, выбирать камеры по требованиям к железу и сцене, строить архив метаданных и держать MQTT-штормы под контролем. Сделанный хорошо, Profile M сокращает интеграцию с месяцев до недель и оставляет открытой дверь любому будущему потребителю аналитики, о котором вы пока не думали.

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