Руководство пользователя¶

Полное наименование: Компонент управления моделями видеоаналитики Обозначение: LPI-VAP-MM Краткое наименование (для работы с документом): «Управление моделями» Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0») Стандарт: ГОСТ 19.505-79

Аннотация¶

Настоящий документ является руководством пользователя компонента управления моделями видеоаналитики (LPI-VAP-MM) — расширения программного продукта «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»; далее — Платформа 4.0). Документ предназначен для пользователей с административными полномочиями, которые ведут каталог моделей видеоаналитики, загружают и версионируют модели, готовят проверочные данные, публикуют версии для автоматической валидации, выполняют их проверку и определяют пригодность для применения в сценариях.

Работа с компонентом выполняется через веб-браузер; установка программ на рабочее место не требуется. Состав доступных разделов и операций определяется ролью и полномочиями учётной записи.

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

1. Назначение программы¶

1.1. Область применения и решаемые задачи¶

Компонент применяется для подготовки моделей видеоаналитики к использованию в Платформе 4.0. После загрузки и распаковки пакета пользователь переводит версию из черновика в опубликованное состояние командой «Сохранить и валидировать». Опубликованная версия проходит автоматическую валидацию и подготовку исполняемых артефактов, после чего может быть проверена на контрольных данных и применена в сценариях видеоаналитики.

Пользователь компонента решает следующие задачи:

• ведёт каталог моделей и распределяет их по каталогам (разделам);
• загружает пакеты моделей и создаёт именованные версии;
• контролирует ход и результат автоматической проверки загруженной версии;
• ведёт метаданные моделей: тип задачи, тип модели, описание, атрибуты в виде пар «ключ — значение», комментарии;
• готовит наборы проверочных данных (ассеты) и их версии;
• выполняет проверку версии модели на выбранной версии ассета и анализирует результаты;
• публикует версию для автоматической валидации, фиксирует результат проверки на контрольных данных и определяет её пригодность к использованию;
• контролирует применение модели в сценариях и выполняет массовое обновление версии модели в сценариях;
• переносит неактуальные модели и версии в архив и восстанавливает их.

Обучение моделей, разработка и отладка сценариев видеоаналитики и применение моделей к рабочим видеопотокам в компоненте не выполняются: разработка сценариев относится к компоненту среды разработки сценариев видеоаналитики (LPI-VAP-RS), а применение опубликованных версий к камерам — к Центральному модулю управления данными и распределёнными вычислениями (LPI-VAP-CORE).

1.2. Функциональные возможности, доступные пользователю¶

Таблица 1.2.1 — Функциональные возможности, доступные пользователю.

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

1.3. Роли пользователей и разграничение доступа¶

Единую точку входа предоставляет LPI-VAP-CORE: Центральный модуль выполняет аутентификацию пользователя через систему управления доступом к информационным ресурсам города Москвы (СУДИР), проверяет групповое право и передаёт LPI-VAP-MM пользовательский контекст. Роль, полномочия и область видимости ведутся средствами Платформы 4.0.

Самостоятельная аутентификация пользователя и непосредственное взаимодействие LPI-VAP-MM с СУДИР не выполняются. Компонент проверяет полномочия из полученного контекста при каждой защищённой операции.

Доступ к функциям определяется тремя параметрами учётной записи:

1. роль — именованный набор разрешённых разделов и операций;
2. полномочия — разрешения на отдельные действия, включая изменение, публикацию, архивирование и запуск проверки;
3. область видимости — перечень объектов Платформы 4.0, доступных пользователю; для LPI-VAP-MM она применяется совместно с полномочиями на модели, ассеты и запуски.

В базовой ролевой модели функции LPI-VAP-MM относятся к административным. Распределение доступа приведено в таблице 1.3.1.

Таблица 1.3.1 — Распределение возможностей по ролям.

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

Операции, на которые у пользователя нет полномочия, в интерфейсе не отображаются либо отклоняются с соответствующим сообщением. Все действия пользователей регистрируются в журнале аудита. Матрица ролей и полномочий конкретной поставки приводится в руководстве администратора.

2. Условия выполнения программы¶

2.1. Требования к техническим средствам рабочего места¶

Таблица 2.1.1 — Технические средства рабочего места.

Требования согласованы с подразделом 4.2 документа «Описание программы».

2.2. Требования к программному обеспечению рабочего места¶

Таблица 2.2.1 — Программное обеспечение рабочего места.

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

2.3. Общие характеристики входной и выходной информации¶

Учётные данные пользователь вводит на странице входа СУДИР; в экранных формах компонента они не запрашиваются и не хранятся.

Пользователь вводит:

• сведения о модели: наименование, тип задачи, тип модели, каталог, описание, атрибуты в виде пар «ключ — значение»;
• пакет модели в формате ZIP, номер и описание версии;
• сведения об ассете, его версии и загружаемые проверочные файлы;
• параметры запуска проверки: тип запуска, модель или сценарий, версия, ассет и его версия;
• результат проверки и комментарии.

Пользователь получает:

• перечень моделей с актуальными версиями, типами задачи и модели, атрибутами и датами изменения;
• перечень версий модели с состоянием обработки и признаком применения;
• перечень ассетов и их версий;
• перечень запусков проверки с состоянием обработки и результатом;
• покадровые результаты работы модели, журналы выполнения и сообщения об ошибках.

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

Таблица 2.3.1 — Подготовка и обработка пользовательских данных.

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

Подробный состав входных и выходных данных приведён в разделах 6 и 7 документа «Описание программы».

2.4. Требования к квалификации пользователя¶

Пользователь должен:

• владеть навыками работы с персональным компьютером и веб-браузером;
• знать состав и структуру пакета модели, применяемого в Платформе 4.0;
• понимать назначение типов задач и типов моделей, категорий детекции и показателей уверенности распознавания;
• знать настоящее руководство в части выполняемых им задач.

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

3. Выполнение программы¶

Работа с компонентом выполняется в веб-интерфейсе Платформы 4.0 в разделах «Настройки → Модели», «Настройки → Ассеты» и «Настройки → Запуски». Порядок работы приведён по типовым задачам: каждый подраздел начинается с назначения описываемого функционала — для чего он нужен и какую задачу управления моделью решает, — после чего процедура описана последовательностью шагов с указанием исходного состояния, выполняемых действий и ожидаемого результата. Наименования разделов, экранных форм, полей и кнопок приведены так, как они отображаются в интерфейсе. Состав объектов на иллюстрациях является демонстрационным.

Перед началом работы должны выполняться следующие условия:

• учётной записи предоставлены групповое право доступа к Платформе 4.0 и административные полномочия на требуемые операции LPI-VAP-MM;
• браузеру разрешены JavaScript, cookie, перенаправление на страницу СУДИР и WebSocket-соединения;
• пакет модели и проверочные данные подготовлены в форматах, согласованных для целевой поставки;
• при замене версии известны сценарии и камеры, которые могут быть затронуты изменением.

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

Основной пользовательский процесс показан на схеме 3.1.

Схема 3.1 — Подготовка версии модели к применению.

3.1. Начало работы¶

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

3.1.1. Вход в систему и переход к компоненту¶

Вход подтверждает личность пользователя, а переданные Центральным модулем роль и полномочия определяют, доступны ли ему операции над моделями, ассетами и запусками. Переход через единый интерфейс исключает отдельную учётную запись для компонента управления моделями.

1. Откройте в браузере адрес веб-интерфейса Платформы 4.0. Если действующего сеанса нет, единая точка входа LPI-VAP-CORE перенаправит браузер на страницу входа СУДИР.
2. Введите учётные данные только на странице СУДИР и подтвердите вход.
3. После возврата в Платформу 4.0 убедитесь, что в боковом меню доступен раздел «Настройки» и его административные пункты.
4. Выберите «Модели» для работы с каталогом, «Ассеты» — для проверочных данных либо «Запуски» — для проверок моделей и сценариев.
5. Если пункты не отображаются, не переходите к ним по прямому адресу: обратитесь к администратору для проверки роли и полномочий.

Признак успешного перехода — открытие страницы «Модели» с деревом каталогов и панелью фильтров.

На стенде разработки может применяться локальная форма входа. Она не является целевым способом аутентификации и в эксплуатационном контуре заменяется входом через СУДИР.

3.1.2. Экранные формы компонента¶

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

Таблица 3.1.1 — Экранные формы компонента.

3.1.3. Завершение сеанса¶

Завершение сеанса исключает выполнение операций под учётной записью пользователя посторонним лицом, особенно на рабочем месте коллективного пользования. При этом уже принятые сервером длительные задачи не прерываются.

Перед выходом сохраните изменения и дождитесь завершения загрузки файлов в браузере. Затем откройте меню учётной записи и выполните выход. На общем рабочем месте после выхода закройте браузер либо завершите сеанс СУДИР.

Выполняемые проверки и конвертация продолжаются на серверной стороне независимо от сеанса пользователя; их состояния и результаты доступны при следующем входе. Несохранённые значения открытой формы при выходе утрачиваются.

3.2. Ведение каталога моделей¶

Каталог нужен для формирования единого управляемого перечня моделей, доступных Платформе 4.0. Он помогает отделять модели разного назначения, находить нужный объект по его характеристикам и не допускать использования неидентифицированных пакетов вне процесса версионирования и проверки.

3.2.1. Просмотр каталога, поиск и фильтрация¶

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

Раздел «Настройки → Модели» (рисунок 3.1) содержит дерево каталогов и перечень моделей.

Рисунок 3.1 — Раздел «Модели»: панель действий и фильтров.

Порядок работы:

1. Задайте условия отбора: «Название модели», «Тип задачи», «Тип модели», «Атрибут» и «Значение атрибута»; при необходимости укажите временной отрезок кнопкой «+ Выбрать временной отрезок».
2. Нажмите «Показать». Кнопка «Сбросить» очищает условия отбора.
3. Раскройте нужный каталог или группу «Модели без каталога» — отобразится перечень моделей (рисунок 3.2).

Рисунок 3.2 — Перечень моделей в каталоге.

Перечень содержит столбцы: «Название модели», «Актуальная версия», «Дата обновления», «Тип задачи», «Тип модели», «Атрибуты», «Описание». В строке модели доступны действия: перемещение в другой каталог, переход к редактированию и перемещение в архив.

3.2.2. Ведение каталогов¶

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

1. Нажмите «Добавить каталог» и укажите его наименование.
2. Для изменения каталога воспользуйтесь действием «Редактировать каталог» в строке каталога.
3. Для удаления каталога воспользуйтесь действием «Удалить каталог»: действие доступно только для каталога, не содержащего моделей.
4. Для переноса модели в другой каталог воспользуйтесь действием перемещения в строке модели.

После создания или переименования убедитесь, что каталог отображается в дереве и раскрывается. Перед удалением перенесите из него все модели. Если после переноса модель не видна, сбросьте фильтры: активные условия отбора применяются и к содержимому нового каталога.

Перемещение изменяет только расположение модели в каталоге. Версии, результаты проверок, комментарии и связи со сценариями сохраняются. Создавать отдельную модель для изменения её каталога не требуется.

3.2.3. Создание и изменение модели¶

Карточка модели создаёт устойчивую запись о назначении и типе модели, к которой затем привязываются её версии. Это позволяет обновлять исполняемый пакет без создания несвязанных записей и сохранять единый контекст применения модели.

1. Нажмите «Добавить модель».
2. Заполните поля: «Название модели», «Тип задачи», «Тип модели», «Каталог», «Описание».
3. При необходимости добавьте атрибуты: в разделе «Атрибуты» нажмите «Добавить» и укажите «Ключ» и «Значение». Атрибуты используются при поиске моделей в каталоге.
4. Сохраните форму.
5. Убедитесь, что модель появилась в перечне выбранного каталога.

Изменение сведений о модели выполняется в форме «Редактирование модели», открываемой действием редактирования в строке модели.

Таблица 3.2.1 — Назначение полей карточки модели.

Тип задачи или тип модели изменяйте только до подготовки рабочих версий либо после оценки влияния на них. Такое изменение не преобразует уже загруженные файлы автоматически. После сохранения откройте карточку повторно и проверьте отображаемые значения.

3.2.4. Комментарии к модели¶

Комментарии нужны для передачи между пользователями сведений, которые не относятся к формализованным полям: происхождение модели, ограничения, особенности проверки и принятые решения. Автор и время комментария обеспечивают прослеживаемость такого пояснения.

В карточке модели доступен блок комментариев: введите текст в поле «Добавить комментарий» и нажмите «Отправить». Комментарии сохраняются с указанием автора и времени и используются для фиксации сведений о происхождении модели, условиях её применения и результатах проверок.

В комментарии рекомендуется ссылаться на номер версии и идентификатор запуска, если пояснение относится к конкретной проверке. Комментарий не заменяет поле «Описание», формальную фиксацию результата запуска или утверждённое решение о допуске. Перед отправкой проверьте текст: опубликованный комментарий становится частью общей истории работы с моделью.

3.3. Работа с версиями моделей¶

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

Карточка модели (рисунок 3.3) открывается из перечня моделей и содержит перечень версий, основную информацию, атрибуты и комментарии.

Рисунок 3.3 — Карточка модели с перечнем версий.

Перечень версий содержит столбцы: «Версия», «Дата загрузки», «Описание», «Применена в» (число сценариев и камер), «Статус» и «Загружен». Черновая версия отмечается признаком «Черновая версия»; для неё доступны редактирование и удаление. В панели «Основная информация» приведены тип задачи, тип модели, описание и число сценариев, в которых применена модель.

3.3.1. Загрузка новой версии модели¶

Загрузка создаёт в карточке модели отдельную редакцию исполняемого пакета и передаёт её серверным средствам подготовки. Она применяется при выпуске новых весов, изменении структуры пакета или исправлении ранее выявленных недостатков.

1. В карточке модели нажмите «Добавить новую версию» — откроется форма «Загрузка новой версии модели» (рисунок 3.4).

Рисунок 3.4 — Форма загрузки новой версии модели.

1. Проверьте поле «Номер версии»: оно заполняется следующим номером автоматически и может быть изменено.
2. Заполните поле «Описание» — назначение версии и внесённые изменения.
3. Нажмите «Выбрать zip-архив» и укажите подготовленный пакет модели.
4. Нажмите «Загрузить архив». Кнопка «Отмена» прекращает загрузку.
5. Дождитесь состояния «Архив успешно распакован». Затем проверьте сведения версии и выберите «Сохранить как черновик» либо «Сохранить и валидировать». Во втором случае версия будет опубликована и начнётся её автоматическая проверка (подраздел 3.3.2). Опубликованная версия появляется в списке выбора при создании запуска; черновая версия в этом списке не отображается.

3.3.2. Контроль автоматической проверки версии¶

Контроль автоматической проверки нужен для того, чтобы не передать в сценарии повреждённый, несовместимый или неработоспособный пакет. По состоянию версии пользователь определяет, продолжается ли обработка, можно ли переходить к проверке на ассете либо требуется исправить пакет или обратиться к администратору.

Обработка состоит из двух последовательных частей. При загрузке выполняются базовая проверка и распаковка архива. После команды «Сохранить и валидировать» выполняются конвертация, валидация и контрольный запуск модели. Черновик после успешной распаковки может оставаться в состоянии unpack_done до передачи на валидацию. Ход и результат отображаются в столбце «Статус» перечня версий.

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

Таблица 3.3.1 — Состояния обработки версии модели.

3.3.3. Создание копии последней версии¶

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

1. В карточке модели нажмите «Создать копию последней версии».
2. Проверьте, что в форме указан пакет именно той исходной версии, которую требуется использовать. Операция копирует последнюю версию, а не выбранную произвольную строку перечня.
3. Укажите новый уникальный номер и описание изменений.
4. Выберите «Сохранить как черновик», если требуется дополнительная настройка, либо «Сохранить и валидировать» для публикации и запуска автоматической проверки.
5. Убедитесь, что новая версия появилась отдельной строкой и получила ожидаемое состояние.

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

3.3.4. Просмотр и редактирование версии¶

Просмотр и редактирование нужны для проверки состава версии и настройки пользовательского представления результатов: категорий детекции, их названий, цветов и дополнительных параметров. Корректные метаданные обеспечивают однозначное отображение результатов в сценариях и событиях.

1. В перечне версий откройте нужную версию.
2. Просмотрите номер, описание, происхождение и сведения о загруженном архиве.
3. В разделе категорий сопоставьте категорию модели с полным и кратким наименованиями, выберите цвет визуализации и проверьте дополнительные параметры.
4. Если интерфейс предоставляет редактирование JSON-параметров категории, изменяйте только ключи, предусмотренные форматом модели. Некорректный JSON не сохраняйте.
5. Сохраните изменения и повторно откройте версию для контроля.

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

3.3.5. Публикация версии¶

Публикация переводит версию из черновика в состояние, в котором она доступна серверным процессам автоматической валидации и спискам выбора. В текущем интерфейсе это не отдельное действие после проверочного запуска: публикация выполняется командой «Сохранить и валидировать» до завершения автоматической и пользовательской проверок.

Только опубликованные версии отображаются в поле «Версия» при создании запуска. Перед созданием запуска дождитесь успешного завершения автоматической проверки со статусом «Протестировано». Перед применением опубликованной версии в рабочем сценарии дополнительно учитывайте зафиксированный результат проверки на ассете и принятый у заказчика порядок допуска моделей.

После публикации:

• версия становится доступна в компоненте среды разработки сценариев видеоаналитики (LPI-VAP-RS) при формировании сценария;
• сценарии с этой версией могут быть назначены камерам средствами Центрального модуля управления данными и распределёнными вычислениями (LPI-VAP-CORE).

3.4. Подготовка проверочных данных¶

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

Раздел «Настройки → Ассеты» (рисунок 3.5) содержит наборы проверочных данных.

Рисунок 3.5 — Раздел «Ассеты».

Версионирование ассетов обеспечивает воспроизводимость: каждый запуск связан с конкретной неизменяемой после публикации версией набора данных.

3.4.1. Поиск, каталоги и создание ассета¶

1. Для поиска задайте «Название ассета», «Атрибут», «Значение атрибута» и при необходимости временной отрезок; нажмите «Показать». Кнопка «Сбросить» возвращает исходный перечень.
2. Для организационной группировки нажмите «Добавить каталог», задайте уникальное понятное имя и сохраните его. Пустой каталог можно удалить.
3. Нажмите «Добавить ассет».
4. Заполните «Название ассета», «Каталог», «Тип», «Описание» и при необходимости атрибуты. Для типа доступны значения «Фото» и «Видео».
5. Нажмите «Сохранить». Компонент создаст ассет и его первую черновую версию с начальным номером 1.0.0, после чего откроет форму наполнения версии.

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

Таблица 3.4.1 — Поля ассета.

3.4.2. Создание и заполнение версии ассета¶

1. В перечне версий откройте существующую черновую версию либо нажмите «Создать новую версию». Новую версию нельзя создать, пока у ассета уже есть неопубликованный черновик.
2. Проверьте автоматически предложенный номер версии и при необходимости измените его; номер должен быть уникален в пределах ассета.
3. Заполните описание версии и атрибуты. Укажите, чем состав отличается от предыдущей версии и для какой проверки подготовлен.
4. Создайте папки кнопкой «Добавить папку». Системная папка «Файлы без папки» предназначена для материалов, которым отдельная группа не нужна.
5. Выберите целевую папку в области загрузки и добавьте файлы с компьютера либо перетащите их в область загрузки.
6. Дождитесь окончания передачи каждого файла. Во время загрузки отображается прогресс; до её завершения не публикуйте версию и не закрывайте страницу.

Для ассета типа «Фото» интерфейс принимает JPG, PNG и GIF, для типа «Видео» — MP4. Имена файлов внутри версии должны быть уникальными. Предельный размер передачи задаётся поставкой; при отклонении файла проверьте его тип и размер и не меняйте расширение без фактического преобразования формата.

3.4.3. Организация файлов и разметка зон¶

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

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

Зоны применяются, когда результат требуется оценивать только в определённой области кадра. Они относятся к конкретному файлу и версии ассета; публикация другой версии не переносит исправленную разметку в ранее созданные запуски.

3.4.4. Сохранение, публикация и комментарии¶

Если подготовка не завершена, нажмите «Сохранить как черновик». Черновик можно повторно открыть и изменить, но он отсутствует в списке версий ассета при создании запуска.

Перед публикацией проверьте номер, описание, список папок и файлов, возможность просмотра материалов и разметку зон. Нажмите «Опубликовать». Опубликованная версия становится доступна для запусков и открывается в режиме просмотра; изменение её состава не допускается. Для корректировки создаётся следующая версия ассета.

Комментарии к ассету и версии используйте для фиксации происхождения данных, условий контрольной выборки и известных ограничений. Кнопки «Архив версий» и «Архив ассетов» открывают архивные записи; порядок работы с ними приведён в 3.7.

3.5. Проверка модели на проверочных данных¶

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

3.5.1. Создание запуска¶

Создание запуска связывает конкретную версию модели с конкретной версией ассета. Такая связь делает результат воспроизводимым и позволяет однозначно установить, какой пакет и какие исходные данные проверялись. В списках выбора отображаются только опубликованные, неархивные и неудалённые версии модели и ассета; черновики для запуска недоступны.

1. Откройте раздел «Настройки → Запуски» и нажмите «Добавить запуск» — откроется форма «Запуск» (рисунок 3.6).

Рисунок 3.6 — Форма создания запуска проверки.

1. В поле «Тип запуска» выберите проверяемый объект: модель или сценарий.
2. В поле «Название» выберите модель, в поле «Версия» — опубликованную версию, для которой автоматическая проверка завершилась успешно. Если версия не отображается, вернитесь в её карточку и проверьте, что была выполнена команда «Сохранить и валидировать», а версия не помещена в архив.

Рисунок 3.7 — В списке запуска отображаются только версии модели, готовые к использованию.

Например, если в карточке модели версии 13.0.0 и 13.0.1 имеют состояние «Версия прошла тестирование и готова к использованию», а версия 13.0.2 остаётся черновой в состоянии «Архив успешно распакован», список выбора содержит только 13.0.0 и 13.0.1. Отсутствие 13.0.2 в списке является штатным ограничением, а не ошибкой загрузки формы. 4. В поле «Ассет» выберите набор проверочных данных, в поле «Версия» — его версию. 5. Нажмите «Запустить».

3.5.2. Контроль выполнения¶

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

Запуск выполняется асинхронно. После нажатия «Запустить» поля выбора блокируются, создаётся идентификатор запуска и начинается последовательная обработка файлов версии ассета. Не нажимайте кнопку повторно в другом окне: сначала убедитесь, что исходный запуск отсутствует в перечне.

Таблица 3.5.1 — Состояния проверочного запуска.

В правой части формы находится блок «Файлы». Выберите файл, чтобы видеть его кадр и локальный прогресс. Вкладки «Лог», «Лог фрейма», «Лог сообщений» и «События» решают разные задачи:

• «Лог» показывает ход сессии в целом;
• «Лог фрейма» помогает разобрать обработку выбранного кадра;
• «Лог сообщений» содержит сообщения исполняемого сценария или модели;
• «События» показывает полученные детекции и связанные данные.

Кнопка «Остановить» прекращает выполняющийся запуск, но не превращает уже полученные частичные данные в завершённый результат. При состоянии ошибки форма позволяет повторно запустить обработку. Повтор выполняйте после проверки доступности модели и ассета и устранения причины, иначе будет воспроизведён тот же отказ.

3.5.3. Анализ результатов и фиксация результата проверки¶

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

1. По завершении обработки просмотрите результаты покадрово, перемещая ползунок под областью просмотра: на кадрах отображаются рамки обнаруженных объектов, наименования категорий и значения уверенности распознавания.
2. Ознакомьтесь с журналами на вкладках блока «Файлы» и, при необходимости, с перечнем сформированных событий.
3. В блоке «Результат» выберите одно из значений: «Тест пройден», «Тест пройден с ошибками», «Тест не пройден».
4. Нажмите «Сохранить результат».
5. При необходимости добавьте комментарий в блоке «Комментарии».

Зафиксированный результат отображается в перечне запусков в столбце «Результат» и используется при принятии решения о применении версии модели.

Результат доступен для выбора только у запуска со состоянием completed. После сохранения результат и его описание блокируются для редактирования, поэтому до нажатия «Сохранить результат» проверьте выбранное решение. Значения трактуются следующим образом:

Таблица 3.5.2 — Интерпретация результата проверки.

3.5.4. Перечень запусков¶

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

Раздел «Настройки → Запуски» (рисунок 3.8) содержит перечень выполненных и выполняемых проверок.

Рисунок 3.8 — Перечень запусков.

Порядок работы:

1. Задайте условия отбора: «Тип запуска», «Название» и «Версия» проверяемого объекта, «Ассет» и его «Версия», период с быстрым выбором «Час», «Сегодня», «Сутки», «Неделя», «Месяц».
2. Нажмите «Показать»; кнопка «Сбросить» очищает условия отбора.
3. Ознакомьтесь с перечнем: «Дата», «Тип запуска», «Модель/Сценарий», «Используемый ассет», «Размер», «Обработка», «Результат».
4. Откройте запуск для просмотра результатов (подраздел 3.5.3).

По умолчанию установлен период последних 24 часов. Если известный запуск не отображается, сначала расширьте период и сбросьте остальные фильтры. Индикатор «Обработка» описывает техническое завершение, а столбец «Результат» — решение, зафиксированное пользователем; отсутствие результата у обработанного запуска означает, что экспертная оценка ещё не сохранена.

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

3.6. Применение модели в сценариях¶

Сведения о применении нужны для оценки последствий изменения версии модели: они показывают, какие сценарии и камеры зависят от неё. Это позволяет не удалить используемую версию и спланировать обновление без незаметного изменения работы видеоаналитики.

3.6.1. Контроль применения¶

Контроль применения нужен перед редактированием, архивированием или заменой версии. По перечню зависимостей пользователь определяет затрагиваемые сценарии и камеры и может проверить их после изменения.

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

Версия, применённая в сценариях, защищена от удаления: перед удалением требуется освободить её от использования.

3.6.2. Массовое обновление версии модели в сценариях¶

Массовое обновление нужно для согласованного перевода выбранных сценариев на новую версию модели без ручного изменения каждого сценария. Оно сокращает число однотипных операций и позволяет явно ограничить состав обновляемых сценариев.

1. В карточке модели нажмите «Обновить сценарии до версии».
2. Выберите целевую версию модели.
3. Отметьте сценарии, в которых требуется заменить используемую версию.
4. Подтвердите операцию.
5. Ознакомьтесь с результатом по каждому выбранному сценарию. Групповая операция может завершиться частично, если один из сценариев недоступен или не допускает замену.
6. Убедитесь, что в перечне версий изменились значения столбца «Применена в».
7. Откройте новые версии изменённых сценариев в LPI-VAP-RS и проверьте каждую из них до применения на камерах.

Изменение сценариев выполняется средствами компонента среды разработки сценариев видеоаналитики: для затронутых сценариев формируются новые версии.

Целевую версию выбирайте только после успешной автоматической проверки и зафиксированной пользовательской оценки. Массовая замена изменяет ссылки в выбранных сценариях, но сама по себе не подтверждает их функциональную эквивалентность и не назначает новые версии сценариев камерам.

3.7. Архив моделей и версий¶

Архив нужен для удаления неактуальных записей из рабочего каталога без немедленной утраты истории и возможности восстановления. Защита используемых версий от архивирования предотвращает нарушение работы связанных сценариев и камер.

Архив предусмотрен отдельно для моделей, версий моделей, ассетов и версий ассетов. Перемещение в архив отличается от физического удаления: архивная запись исключается из обычных списков выбора, но может быть возвращена в рабочее хранилище.

3.7.1. Архивирование модели или версии модели¶

1. Проверьте столбец «Применена в» и откройте перечень зависимых сценариев и камер.
2. Если версия используется, замените её в сценариях и завершите применение соответствующих версий сценариев на камерах средствами LPI-VAP-RS и LPI-VAP-CORE.
3. Обновите карточку и убедитесь, что зависимостей нет.
4. Для модели используйте действие «Перенести в архив» в строке каталога; для отдельной версии — действие архивирования в перечне версий.
5. Подтвердите операцию и убедитесь, что запись исчезла из рабочего перечня и появилась в «Архиве моделей» или «Архиве версий моделей».

Архивирование всей модели затрагивает доступность всех её версий в рабочих списках. Если неактуальна только одна версия, архивируйте версию, а не модель. Черновая версия, не требующая сохранения истории, может удаляться без переноса в архив после подтверждения операции.

3.7.2. Архивирование ассета или версии ассета¶

1. Проверьте, используется ли версия в сохранённых или выполняемых запусках и требуется ли она для воспроизведения результата.
2. Завершите или остановите связанные активные запуски.
3. В разделе «Ассеты» выберите архивирование ассета либо откройте перечень его версий и архивируйте опубликованную версию.
4. Убедитесь, что запись доступна в «Архиве ассетов» или «Архиве версий».

Ассет с неопубликованной версией нельзя переносить в архив, пока черновик не опубликован либо не удалён. Для опубликованной версии действие удаления означает перенос в архив; неопубликованный черновик удаляется окончательно.

3.7.3. Восстановление и окончательное удаление¶

В верхней части каждого архива отображается поле «Время хранения» (для ассетов — «Время хранения ассета»). Значение задаётся в сутках отдельно для моделей, версий моделей, ассетов и версий ассетов. После нажатия «Применить» система пересчитывает срок хранения; остаток отображается в столбце «До окончания хранения». Не изменяйте значение без согласованного регламента: уменьшение срока может приблизить автоматическое удаление уже архивированных объектов.

1. Откройте соответствующий архив и проверьте срок хранения.
2. Задайте условия поиска и отметьте одну или несколько записей.
3. Нажмите «Вернуть в хранилище» и подтвердите действие.
4. Найдите восстановленный объект в рабочем каталоге и проверьте его версии и файлы. Восстановление не возобновляет прежние назначения в сценариях и на камерах автоматически.

Окончательное удаление из архива применяйте только после истечения срока хранения, проверки отсутствия зависимостей и подтверждения наличия требуемой резервной копии. Восстановление средствами интерфейса после окончательного удаления невозможно. Срок хранения и полномочия на эту операцию устанавливаются для целевой поставки.

3.8. Завершение работы¶

Завершение работы нужно для сохранения введённых данных и защиты учётной записи. Перед выходом достаточно завершить передачу файлов и сохранить формы: уже принятые сервером проверки и конвертации продолжатся независимо от браузера.

1. Завершите передачу загружаемых файлов и сохраните изменения в открытых формах. Уже принятые сервером проверки и конвертации можно оставить выполняться.
2. Выйдите из учётной записи.
3. Закройте вкладку браузера.

При следующем входе проверьте состояние оставленных задач в перечне версий или запусков.

4. Сообщения пользователю¶

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

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

4.1. Информационные сообщения¶

Таблица 4.1.1 — Информационные сообщения.

4.2. Предупреждающие сообщения¶

Таблица 4.2.1 — Предупреждающие сообщения.

4.3. Сообщения об ошибках¶

Таблица 4.3.1 — Категории сообщений об ошибках.

4.4. Действия при сбоях¶

Таблица 4.4.1 — Действия при сбоях.

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

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

Приложения¶

Приложение А (справочное). Экранные формы интерфейса¶

Таблица А.1 — Экранные формы интерфейса.

Иллюстрации получены на действующей установке; состав моделей, ассетов и запусков на иллюстрациях является демонстрационным.

Приложение Б (рекомендуемое). Типовые задачи пользователя¶

Сценарии показывают, как процедуры раздела 3 объединяются в законченные рабочие процессы. Все сценарии выполняет пользователь с ролью «Администратор» либо с эквивалентным набором административных полномочий.

Б.1. Ввод и проверка новой модели¶

Цель — получить воспроизводимо проверенную версию модели, готовую к применению в сценариях.

1. Создайте модель и заполните её тип, описание и атрибуты (3.2.3).
2. Загрузите ZIP-пакет как новую версию (3.3.1).
3. После распаковки пакета выберите «Сохранить и валидировать». Версия будет опубликована и передана на автоматическую проверку (3.3.1).
4. Дождитесь успешного завершения автоматической проверки и конвертации (3.3.2).
5. Подготовьте и опубликуйте версию ассета с контрольными изображениями или видео (3.4).
6. Создайте проверочный запуск, выбрав опубликованную версию модели, проанализируйте кадры и журналы и зафиксируйте результат (3.5).
7. При положительном результате используйте версию в сценариях в соответствии с порядком допуска моделей; при отрицательном создайте исправленную версию, опубликуйте её командой «Сохранить и валидировать» и повторите проверки.

Б.2. Замена версии модели в сценариях¶

Цель — перевести выбранные сценарии на проверенную версию без потери прослеживаемости.

1. Убедитесь, что целевая версия прошла автоматическую и пользовательскую проверку и готова к применению.
2. Посмотрите число сценариев и камер для текущей версии в столбце «Применена в» (3.6.1).
3. Выполните массовое обновление только выбранных сценариев (3.6.2).
4. Проверьте результат для каждого сценария: групповая операция может быть выполнена частично, если отдельный сценарий недоступен или несовместим.
5. Передайте новые версии сценариев на функциональную проверку и применение к камерам в установленном порядке.

Б.3. Вывод версии модели из эксплуатации¶

Цель — исключить неактуальную версию из рабочего каталога, не нарушив работу сценариев и камер.

1. Проверьте применение версии в сценариях и камерах (3.6.1).
2. Замените её в используемых сценариях либо снимите соответствующие назначения средствами LPI-VAP-RS и LPI-VAP-CORE.
3. Повторно убедитесь, что число зависимостей равно нулю.
4. Переместите версию в архив (3.7).
5. Не удаляйте архивную запись физически до истечения установленного срока хранения и подтверждения отсутствия зависимостей.

Б.4. Разбор зависшего проверочного запуска¶

Цель — определить, можно ли безопасно повторить проверку.

1. Обновите карточку запуска и проверьте состояние каждого файла и общий процент выполнения (3.5.2).
2. Проверьте доступность выбранной версии модели и версии ассета.
3. Ознакомьтесь с общим и покадровым журналами; зафиксируйте первое сообщение об ошибке и идентификатор запуска.
4. Если сервер не принял задачу, повторите запуск. Не создавайте параллельные дубликаты, пока состояние исходного запуска не выяснено.
5. При повторении передайте в службу сопровождения сведения из подраздела 4.4.

Б.5. Подготовка новой версии проверочного набора¶

Цель — изменить контрольные данные, сохранив воспроизводимость ранее выполненных проверок.

1. Откройте ассет и убедитесь, что его тип соответствует новым материалам.
2. Не изменяйте опубликованную версию: нажмите «Создать новую версию» (3.4.2).
3. Укажите новый номер и опишите причину изменения набора.
4. Создайте требуемые папки, загрузите файлы и добавьте зоны. Проверьте каждый файл средствами просмотра.
5. Выберите «Сохранить как черновик», если наполнение ещё не завершено. После контрольного просмотра нажмите «Опубликовать».
6. Выполните новый запуск на новой версии ассета. Ранее сохранённые запуски остаются связанными с прежней версией и пригодны для сравнения.

Б.6. Восстановление ошибочно архивированного объекта¶

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

1. Определите вид объекта и откройте соответствующий архив (3.7.3).
2. Найдите запись по наименованию, версии и дате архивирования.
3. Отметьте только требуемые записи и нажмите «Вернуть в хранилище».
4. Сбросьте фильтры рабочего перечня и убедитесь, что объект восстановлен.
5. Проверьте карточку, файлы и состояния. При необходимости заново выполните назначение в сценарии или выберите версию в новом запуске: прежние связи не следует считать восстановленными без проверки.

Приложение В (справочное). Перечень сообщений пользователю¶

Приложение приводит формулировки сообщений, отображаемых в интерфейсе, и служит для их опознания по тексту. Классификация сообщений, связь с операциями и порядок действий приведены в разделе 4.

Таблица В.1 — Сводный перечень сообщений пользователю.

Приложение Г (обязательное при подготовке целевой поставки). Параметры, задаваемые поставкой¶

В приложении перечислены переменные сведения, которые не относятся к незаполненным функциям руководства: их конкретные значения зависят от контура, производительности оборудования и регламентов заказчика. Пользователь применяет правила таблицы Г.1, а утверждённые значения получает из документов своей поставки.

Таблица Г.1 — Параметры, задаваемые для целевой поставки.

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

Приложение Д (справочное). Исходные тексты схем Mermaid¶

Приложение содержит исходный Mermaid-код графической схемы документа. Схема остаётся в соответствующем разделе, а исходный текст предназначен для её просмотра, копирования и проверки.

Исходные тексты¶

MM-UG-MER-001. Схема 3.1 — Подготовка версии модели к применению¶

Расположение схемы: 3. Выполнение программы.

flowchart LR
    PREP["Подготовить пакет модели"] --> CREATE["Создать модель<br/>и загрузить версию"]
    CREATE --> PUBLISH["Сохранить и валидировать:<br/>опубликовать версию"]
    PUBLISH --> AUTO["Дождаться автоматической<br/>проверки и конвертации"]
    ASSET["Подготовить и опубликовать версию<br/>проверочного ассета"] --> RUN["Запустить проверку<br/>на контрольных данных"]
    AUTO --> RUN
    RUN --> REVIEW{"Результат<br/>приемлем?"}
    REVIEW -->|нет| FIX["Исправить пакет<br/>или метаданные"]
    FIX --> CREATE
    REVIEW -->|да| ACCEPT["Зафиксировать положительный<br/>результат проверки"]
    ACCEPT --> IMPACT["Проверить применение<br/>в сценариях и камерах"]

Лист регистрации изменений¶

Таблица — Лист регистрации изменений

Предфинальная рабочая редакция 0.8 содержит заполненные сведения по всем разделам ГОСТ 19.505-79 и приложениям: назначение и условия работы, полный пользовательский цикл модели, подготовку и версионирование ассетов, состояния и результаты запусков, применение в сценариях, архивирование и восстановление, сообщения и безопасные действия при сбоях. Последовательности и наименования элементов сверены с текущим исходным кодом интерфейса BOX5; переменные адреса, лимиты и регламенты отделены в приложение Г от неизменной процедуры работы. Редакция не является зарегистрированным изменением утверждённого оригинала. При выпуске утверждаемой редакции необходимо:

1. присвоить обозначение документа и формальный номер изменения;
2. сформировать DOCX или PDF и указать фактическое число и номера листов;
3. указать номер сопроводительного документа, если он оформляется;
4. получить подписи ответственного исполнителя, проверяющего и нормоконтролёра в порядке, принятом для проекта;
5. в последующих строках регистрировать только изменения утверждённого оригинала, а не отдельные технические коммиты Git.

История подготовки рабочей редакции сохраняется в Git. Она используется для трассировки исходного текста, но не заменяет оформленный лист регистрации изменений.