BOX 5.0 · Платформа 4.0
Сценарии и блоки: данные, связи и временная логика
Технический разбор сценария контроля СИЗ: детекции, треки, зоны, накопление признаков, формирование и доставка событий.
Подробные инструкции
На этой странице
1. Сообщение связывает блоки
Граф передаёт контейнер полезной нагрузки. Блок читает именованные поля — в документации они также называются топиками — и записывает результат в согласованное поле. Соединительная линия задаёт маршрут сообщения, но не исправляет несовпадающие имена полей.
Минимальная цепочка начинается с VideoFrame. По мере обработки сообщение получает детекции, треки, атрибуты зон, события и изображение с визуализацией. Точная структура объектов определяется версиями блоков и runtime; ниже описаны роли данных, а не универсальная JSON-схема для импорта.

| Данные | Назначение | Что проверить на границе блоков |
|---|---|---|
| image | Исходное изображение | Размер, формат и имя поля |
| image_timestamp | Время кадра | Единицы времени, порядок кадров, источник метки |
| detections | Объекты одного кадра | Категории, bbox, уверенность, система координат |
| tracks | Объекты, связанные во времени | Устойчивый ID, выбранные классы и атрибуты |
| zones | Геометрия и типы зон | Совпадение типа зоны и координат |
| events | Результаты бизнес-правил | Тип, время, объект и доказательство |
| inconsistencies | Дополнительные атрибуты несоответствия | Совместимость справочников принимающей системы |
2. VideoFrame: частота, размер и время
VideoFrame извлекает кадр из потока камеры или тестового видео, задаёт его размер и частоту обработки. В документированном варианте −1 по обеим сторонам сохраняет исходный размер; −1 по одной стороне сохраняет пропорции при изменении другой. Поддержку этих значений нужно сверять с версией формы и блока.
Частота обработки f не обязана равняться частоте видео. При f=5 сценарий анализирует пять кадров в секунду. Снижение f уменьшает вычислительную нагрузку, но меняет наблюдаемость коротких действий и смысл порогов в кадрах.
Используйте временную метку исходного кадра для логики длительности. Скорость офлайн-обработки зависит от оборудования: десять секунд видео могут обрабатываться быстрее или медленнее десяти секунд реального времени. Таймер по времени работы Python-процесса исказит результат.
Для проверки блока «Расписание» в песочнице документирована эмуляция времени через параметр входного блока. Проверьте, какое время подаёт ваш тест: исходную метку записи, виртуальное время или текущее время сервера.

3. Detector: версии, категории и пороги
Detector запускает выбранную версию модели на изображении и формирует детекции. Сначала проверяют совместимость модели со способом исполнения, затем выбирают категории и пороги. Отсутствующий в модели класс нельзя получить простым добавлением его имени в фильтр.
В обучающей документации порог категории и глобальный conf_thres объединяются по максимуму. Например, глобальный 0,60 и частный 0,40 дают эффективный порог 0,60, а частный 0,75 — 0,75. При переносе на другую версию подтвердите это контрольным тестом.
Уверенность модели не является оценкой вероятности бизнес-нарушения. Порог детекции управляет допуском визуального признака; пространственные связи, длительность и правило события настраиваются дальше.
Если рамок нет, сначала проверьте исходный кадр и выбранные категории. Затем формат исполнения, ошибки загрузки модели и пороги. Добавление новых блоков поверх пустого массива затрудняет поиск причины.

4. Tracker: от отдельных рамок к объекту во времени
Трекер связывает детекции одного объекта между кадрами и присваивает устойчивый ID. Для контроля СИЗ обычно отслеживают человека, а каску и другие предметы добавляют как его атрибуты.
В документированном Tracker параметр use_detections переключает использование уже полученных детекций и запуск собственного детектора. Когда перед трекером стоит подходящий Detector, повторный inference может оказаться лишним. Сначала проверьте, какой режим включён.
Разрыв трека влияет на счётчики и подавление повторных событий. Один человек с двумя последовательными ID может породить два независимых накопления признака. Проверяйте перекрытие, выход из кадра, склейку близких людей и повторное появление.
5. DetectionAttacher: чья это каска?
DetectionAttacher связывает детекции атрибутов с треком. В описанном алгоритме проверяется отношение площади пересечения детекции и трека к площади самой детекции: A(detection ∩ track) / A(detection). Это не IoU, у которого знаменатель — площадь объединения.
Небольшая каска внутри рамки человека даст высокую долю пересечения. На тесной сцене одна каска может пересекаться с рамками двух людей. Поэтому проверяют не только успешную привязку, но и отсутствие неверной связи с соседом.
Блок обычно следует за трекером. Если признаки приходят из разных веток, их сначала согласуют по кадру и объединяют. Выбранные имена detections и tracks должны совпадать с выходами предыдущих блоков.
6. Отсутствие признака требует наблюдаемости
AddRelatedDetection создаёт связанный признак отсутствия, когда ожидаемый атрибут не найден. В учебной документации используются main_object — ожидаемая категория, creating_object — создаваемая категория и prefixes — условия по другим видимым атрибутам и размерам.
Например, отсутствие сумки защитного устройства имеет смысл проверять только при достаточно видимом корпусе человека. Порог размера других детекций помогает исключить слишком маленькие или закрытые изображения. Это не делает вывод безошибочным, но задаёт явное условие применимости.
Порядок важен: сначала детектор и трекер, затем привязка атрибутов, затем формирование признака отсутствия и временное правило. Если проверять отсутствие до привязки, ожидаемый атрибут ещё не появится в треке даже при наличии на изображении.
7. Зоны: присвоение атрибута и фильтрация
DetectionsZones проверяет связь объекта с полигоном и добавляет атрибут зоны. Возможные правила используют центр bbox, нижнюю точку или пересечение площадей. Они отвечают на разные вопросы: нижняя точка чаще приближает положение на полу, а пересечение рамки может сработать уже при частичном заходе.
Добавление атрибута зоны не обязательно удаляет объекты вне неё. «Точка скелета в зоне» также описана как присвоение атрибута без фильтрации. Если дальнейшая логика должна получать только объекты внутри, нужен соответствующий фильтр.
«Фильтр по зоне-атрибуту» разделяет треки на два выхода: прошедшие условие и остальные. Проверьте выход, к которому подключили создание события. Перепутанная ветка даёт внешне исправный сценарий с противоположным смыслом.
Тип зоны в справочнике, тип в блоке и геометрия на камере должны соответствовать друг другу. После изменения размера или ракурса исходного изображения повторите проверку границы.
8. Событие по числу кадров и событие по времени
EventNumViols накапливает заданный атрибут трека. min_number_violations — минимальное число кадров с признаком; time_threshold_between_violations — интервал подавления повторной отправки для того же трека.
Порог 10 кадров при обработке 5 кадров/с соответствует примерно двум секундам наблюдений только при регулярной обработке и нужной семантике накопления. Он сам по себе не доказывает десять последовательных кадров или непрерывное нарушение: проверьте сброс состояния и пропуски в вашей версии.
EventDependViols проверяет отсутствие ожидаемой категории за time_depend_viol. Параметр store_state влияет на память о ранее найденной категории: постоянное сохранение признака и повторная проверка по временному окну дают разные события.
Для EventZoneDependViols проектные редакции описывают разные моменты формирования результата: по длительности условия в зоне и после выхода из неё. Перед применением проверьте фактическую версию на трёх тестах: человек остаётся внутри, выходит раньше порога, выходит позже порога. Не переносите момент отправки из названия блока.
| Параметр | Что он ограничивает | Частая ошибка |
|---|---|---|
| Порог уверенности | Допуск детекции | Считать его порогом длительности |
| Число кадров | Количество наблюдений признака | Автоматически трактовать как секунды |
| Временное окно | Длительность по времени кадров | Считать по скорости обработки файла |
| Интервал повторов | Повторные события одного объекта | Ожидать глобальное подавление для всех треков |
| store_state | Сохранение найденного признака | Не учитывать память при повторном эпизоде |
9. Ветвления, слияние и внешний сигнал
Merge объединяет выбранные одноимённые топики нескольких веток. Прежде чем соединять два детектора, согласуйте имена полей и проверьте, что объединяются результаты одного кадра. Само совпадение названий не описывает всю политику синхронизации runtime.
python-switch сравнивает результат выражения с заданным значением и пропускает сообщение при выполнении условия. Строка «1» и число 1 могут вести себя по-разному: проверьте выбранный тип значения.
Блок АСУ ТП направляет сообщение по значению группы сигналов камеры. Для неизвестного или недоступного сигнала используется настроенное значение по умолчанию. Выбор этого значения — часть логики задачи: он определяет, продолжится ли проверка при потере внешних данных.
Блок «Расписание» пропускает сообщение при попадании времени кадра в заданный диапазон. Этот блок фильтрации внутри видеосценария и планировщик запросов кадров к LLM решают разные технические задачи.
10. Python-блок: состояние и выходы
В документированном python3-function переменная msg даёт доступ к входным данным, self позволяет хранить состояние между кадрами, return управляет выходами. None или пустой массив для выхода прекращают прохождение по нему.
Состояние задавайте отдельно для камеры и объекта, если один экземпляр блока способен обрабатывать несколько потоков. Учитывайте очистку при завершении трека, перезапуске и новом тестовом прогоне. Иначе предыдущий ролик может повлиять на следующий.
Не изменяйте существующее поле с общим именем без проверки потребителей. Для промежуточного результата удобно использовать отдельное имя и показать его в диагностике. Исключение внутри блока и отсутствие сообщений на выходе нужно различать.
Ниже псевдокод правила, а не готовый код импорта: реальные поля времени, трека и видимости берутся из описания входных и выходных данных установленного блока.
для каждого кадра в порядке времени:
если источник недоступен или зона неразличима:
состояние = НЕИЗВЕСТНО
не накапливать доказательство отсутствия
иначе если человек наблюдается в зоне:
сбросить начало наблюдаемого отсутствия
состояние = ПРИСУТСТВИЕ
иначе:
начать / продолжить интервал наблюдаемого отсутствия
если интервал >= согласованный порог:
создать событие с временем и доказательством11. Создание, визуализация и отправка — разные этапы
Блок создания событий добавляет результат в events. LocalVisualizer рисует выбранные детекции, треки, зоны и события. EventSender передаёт созданные события в операционный контур. Между созданием и отправкой можно разместить фильтрацию или дополнительную обработку.
Если рамки видны, но журнал пуст, сначала проверьте наличие events в сообщении. Затем подключение EventSender, ожидаемые атрибуты, доступность приёмника и ошибки сохранения. Не увеличивайте чувствительность детектора, пока не установили, на каком этапе исчезает результат.
Для проверки доставки сопоставьте идентификатор, камеру, время и медиа. Отдельно проверьте повторы: повторная обработка ролика или смена track ID не должны незаметно считаться новым реальным происшествием в итогах испытания.

12. Остальные блоки: вход, выход и место в графе
Состав палитры зависит от поставки. Справочник ниже помогает выбрать класс операции; доступные параметры проверяют в карточке конкретного блока.
| Блок | Вход → результат | Особенность |
|---|---|---|
| Классификатор детекций | Кадр + bbox → уточнённые категории | Работает по участкам изображения; не равен LLM-классификации всей сцены |
| Фильтр детекций по размеру | Детекции → детекции допустимого размера | Порог задан в пикселях; зависит от масштаба кадра |
| Ремап категорий | Детекции → переименованные категории | В описанном варианте −1 удаляет детекцию |
| Инстанс-сегментатор | Изображение → объекты с масками | Маска и прямоугольная рамка несут разную геометрию |
| NMS | Пересекающиеся детекции → сокращённый набор | Проверяйте группировку по суперкатегориям |
| Детектор позы человека | Люди на кадре → ключевые точки | Недостающие точки не считать доказательством положения |
| Точка скелета в зоне | Поза + полигон → атрибут зоны | Сам по себе не фильтрует поток |
| Зона по позе | Треки с позой → ветки по условию | Проверьте выбранные ключевые точки и выход |
| Фильтр по категории-атрибуту | Треки → треки с нужным атрибутом | Атрибут должен быть добавлен до фильтра |
| Трекер2 | Наблюдения объектов → треки | Параметры и формат данных сверяют с описанием выбранной реализации |
| Несоответствие | Сообщение → дополнительные атрибуты | Требует согласования справочников получателя |
| Оценка качества изображения | Кадр и контекст → признаки ухудшения | Пересвет, размытие, сдвиг, замирание, загрязнение |
| RegressionBasePoint | Груз, человек, калибровка → положение под грузом | Проектная модель калибруется под конкретную камеру и сцену |
13. План отладки
Начните с входа и добавляйте по одному смысловому этапу. После каждого шага сохраните граф и проверьте контрольные моменты видео. Число блоков не является показателем готовности сценария.

| Этап | Контрольный вопрос |
|---|---|
| Кадр | Правильное видео, размер и временная метка? |
| Детекции | Нужные объекты и категории появились? |
| Треки | Один объект сохраняет ID? |
| Связи | Каска прикреплена к своему человеку? |
| Зона | Пограничный случай попадает в ожидаемую ветку? |
| Время | Порог, сброс и повтор работают на нужных моментах? |
| Событие | Объект events содержит ожидаемый результат? |
| Доставка | Запись появилась в журнале с правильной камерой и медиа? |