Описание программы¶

Полное наименование: Компонент управления моделями видеоаналитики

Обозначение: LPI-VAP-MM

Краткое наименование (для работы с документом): «Управление моделями»

Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»)

Стандарт: ГОСТ 19.402-78

Аннотация¶

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

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

Исполняемые составные части поставляются контейнерными образами и размещаются в кластере Kubernetes Платформы 4.0 на серверных ЭВМ архитектуры x86 под управлением «Московской серверной операционной системы». Выделенные серверы под компонент не требуются: прикладные сервисы каталога моделей, проверочных данных и запусков размещаются на мастер-ноде кластера, а конвертация, валидация, контрольный инференс и проверочные запуски моделей — на вычислительной ноде с графическим ускорителем класса NVIDIA T4. Компоненту выделяется доля ресурсов этих узлов, соответствующая позиции поставки. Метаданные сохраняются в PostgreSQL, двоичные пакеты, проверочные медиаданные и результаты — в S3-совместимом объектном хранилище; обмен заданиями и состояниями выполняется с применением очередей сообщений. Пользователь обращается к компоненту через общий веб-интерфейс Платформы 4.0 с персонального компьютера или тонкого клиента; установка исполняемых частей LPI-VAP-MM на рабочее место не требуется.

Серверная часть реализована преимущественно на Python, пользовательский веб-интерфейс и серверные средства веб-среды — на TypeScript и JavaScript; для представления, хранения и обмена данными также используются HTML, CSS, SQL, JSON, YAML и Protocol Buffers. Объём программы определяется составом контейнерных образов и клиентского приложения конкретной версии поставки и должен фиксироваться по ведомости образов и результатам сборки. Пользовательские модели, проверочные медиаданные и результаты запусков относятся к данным компонента и в объём программы не включаются.

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

1. Общие сведения¶

1.1. Обозначение и наименование программы¶

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

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

Таблица 1.1.1 — Функциональные блоки компонента.

Схема 1.1 — Место LPI-VAP-MM в Платформе 4.0.

1.2. Программное обеспечение, необходимое для функционирования программы¶

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

Уровни программного обеспечения, необходимого для функционирования компонента, приведены на схеме 1.2; состав каждого уровня раскрыт в п. 1.2.1–1.2.5.

Схема 1.2 — Уровни программного обеспечения, необходимого для функционирования компонента.

1.2.1. Системное программное обеспечение¶

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

1.2.2. Общесистемные (инфраструктурные) сервисы Платформы 4.0¶

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

1.2.3. Среды исполнения и системные библиотеки¶

Основные библиотеки и фреймворки:

Компонент принимает пакеты моделей форматов ONNX, PyTorch, TensorFlow и TensorRT. Наличие среды исполнения конкретного исходного формата определяется выбранным образом конвертера; её точная версия должна быть указана в формуляре целевой поставки.

1.2.4. Смежные компоненты Платформы 4.0 и внешние программные средства¶

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

Исполнение опубликованных моделей на рабочих видеопотоках, управление камерами и фиксация событий не входят в границу ответственности LPI-VAP-MM.

1.2.5. Клиентское программное обеспечение¶

Рабочее место пользователя должно иметь сетевой доступ к веб-интерфейсу Платформы 4.0 и веб-браузер с поддержкой HTML5, JavaScript и WebSocket. Могут использоваться Google Chrome версии не ниже 80, Яндекс.Браузер или Mozilla Firefox сопоставимой поддерживаемой версии. Установка исполняемых частей компонента на рабочее место пользователя не требуется.

1.3. Языки программирования¶

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

2. Функциональное назначение¶

Компонент управления моделями видеоаналитики (LPI-VAP-MM) предназначен для централизованной подготовки моделей видеоаналитики к применению в Платформе 4.0. Компонент объединяет в одном контуре ведение версионного каталога моделей, автоматическую проверку загруженных пакетов и проверку моделей на предварительно подготовленных данных. Классы решаемых задач приведены в подразделе 2.1, состав входных и выходных данных — в разделах 6 и 7.

Результатом работы компонента является опубликованная версия модели с проверенными файлами, метаданными и категориями. Непосредственное исполнение этой версии на рабочих видеопотоках выполняется исполняющим ядром видеоаналитики и не относится к функциям LPI-VAP-MM. Компонент также не подключает камеры, не распределяет видеопотоки и не регистрирует события или нарушения промышленного контура.

2.1. Классы решаемых задач¶

Основной функциональный цикл показан на схеме 2.1.

Схема 2.1 — Функциональный цикл подготовки версии модели.

2.2. Сведения о функциональных ограничениях на применение¶

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

• максимальный размер ZIP-пакета модели и отдельного файла модели;
• максимальный объём, количество файлов и длительность видеозаписи в версии проверочного набора данных;
• поддерживаемые видеокодеки внутри контейнера MP4;
• перечень поддерживаемых архитектур моделей и допустимые версии ONNX, PyTorch, TensorFlow и TensorRT;
• предельное количество одновременно выполняемых конвертаций и проверочных запусков.

2.3. Показатели назначения¶

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

Таблица 2.3.1 — Требования к показателям назначения.

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

Показатели обеспечиваются при следующих условиях:

• время открытия списка моделей и версий относится к каталогу штатного объёма и рабочему месту, соответствующему подразделу 4.2;
• время конвертации и валидации отсчитывается от начала обработки загруженного пакета до получения результата проверки и не включает ожидание в очереди при одновременном выполнении нескольких операций;
• число одновременно выполняемых загрузок, конвертаций и проверок не превышает значений, на которые рассчитана конфигурация технических средств (подразделы 4.3 и 4.4).

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

3. Описание логической структуры¶

3.1. Алгоритм программы¶

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

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

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

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

Загрузка новой версии выполняется в следующем порядке:

1. Пользователь выбирает существующую модель либо создаёт карточку модели с указанием раздела, типа задачи, архитектуры, описания и поисковых атрибутов.
2. Веб-интерфейс через API-шлюз передаёт сведения в svr-models-registry. Реестр создаёт запись модели или версии в PostgreSQL и присваивает ей идентификатор.
3. Пользователь передаёт ZIP-пакет. Реестр потоково сохраняет архив в MinIO и инициирует его извлечение в префикс <модель>/<версия>/.
4. Реестр проверяет структуру архива и наличие обязательных файлов протокола модели. Для используемого формата пакета из model_info.json извлекаются сведения о модели, а из coco_categories.json — категории и параметры их отображения.
5. Метаданные файлов, категории и результат распаковки сохраняются в PostgreSQL; сами веса, конфигурации и вспомогательные файлы остаются в объектном хранилище.
6. При обработке архива реестр последовательно устанавливает состояния unpacking_archive и unpack_done. Ошибка базовой проверки устанавливает invalid_archive, ошибка извлечения файлов — unpack_error.
7. После unpack_done черновая версия ожидает решения пользователя. При выборе команды «Сохранить и валидировать» признак публикации устанавливается и реестр передаёт в Kafka событие model_version_uploaded, которое ставит версию в очередь конвертации и валидации. Для версии, уже отмеченной для публикации, событие передаётся сразу после успешной распаковки.
8. Причина каждого неуспешного состояния сохраняется в диагностическом поле; частично извлечённые данные удаляются фоновым заданием.

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

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

3.1.2. Конвертация и валидация модели¶

Автоматическая проверка начинается после получения inf-flows-manager события model_version_uploaded. Обработка одной версии включает следующие этапы:

1. Менеджер переводит версию в состояние in_validation и загружает её файлы из реестра в изолированный рабочий каталог.
2. По описанию модели, её архитектуре и требуемому профилю исполнения выбирается средство конвертации. Для поддерживаемых семейств используются сервисы yolo-conversion или mm-conversion; обращение выполняется по внутреннему HTTP-интерфейсу либо через Unix domain socket в зависимости от профиля развёртывания.
3. Конвертер запускает отдельный процесс, преобразует исходные веса и формирует требуемые ONNX-, TensorRT- или иные исполняемые артефакты. Полученные файлы передаются обратно в объектное хранилище реестра.
4. Менеджер проверяет состав файлов, метаданные, категории и возможность загрузки сформированного представления модели.
5. После успешной валидации версия переводится в состояние in_testing и для неё выполняется контрольный инференс. Этот запуск проверяет техническую работоспособность, но не оценивает точность модели на данных заказчика.
6. При успешном контрольном запуске устанавливается состояние tested. Ошибка конвертации или проверки файлов фиксируется как failed_validation, ошибка контрольного инференса — как failed_testing. Для ошибки, которую нельзя отнести к этим этапам, используется итоговое состояние failed. Этап и причина передаются отдельным диагностическим сообщением.
7. Каждое изменение состояния передаётся в Kafka сообщением model_version_change_status. Реестр сохраняет состояние в PostgreSQL и публикует ws_model_version_change_status для обновления интерфейса.
8. Временный рабочий каталог удаляется независимо от результата обработки.

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

Схема 3.2 — Конвертация и автоматическая проверка версии модели.

3.1.3. Проверка модели на наборе данных¶

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

1. Пользователь выбирает версию модели и опубликованную версию проверочного набора данных и создаёт запуск.
2. svr-launch-storage запрашивает у svr-models-registry и svr-asset-storage метаданные выбранных версий, перечень медиафайлов и ссылки на относящиеся к ним описания зон.
3. Хранилище запусков создаёт в PostgreSQL запись запуска с уникальным идентификатором и контекст первого медиафайла, затем вызывает nr-sbx-backend для создания изолированной сессии типа model.
4. Бэкенд сохраняет временное состояние сессии в Redis, подготавливает рабочий каталог и передаёт задачу process_session исполнителю nr-sbx-celery.
5. Исполнитель получает артефакты модели, при необходимости вызывает nr-sbx-yolo-conversion или nr-sbx-mm-conversion, формирует проверочный граф для типа задачи и обрабатывает изображение либо кадры видеозаписи.
6. Прогресс поступает через Kafka контура проверки в бэкенд. Бэкенд передаёт состояние в основной Kafka, откуда его получает svr-launch-storage.
7. Для набора из нескольких файлов хранилище запусков после завершения очередного файла публикует команду continue_launch; обработка повторяется для следующего файла.
8. Кадры до и после визуализации, журналы, сообщения и события детекции сохраняются в MinIO под идентификатором запуска. Метаданные запуска, состояния файлов и ссылки на артефакты сохраняются в PostgreSQL.
9. После обработки всех файлов запуск получает состояние completed. Ошибка переводит его в failed; пользователь также может остановить выполняемый запуск или повторить его.
10. Веб-интерфейс запрашивает у хранилища запусков количество кадров, исходный и визуализированный кадры, журналы, сообщения и события и отображает рамки, категории и уверенность распознавания.

Схема 3.3 — Проверка модели на версии ассета.

3.1.4. Публикация и применение версии модели¶

После достижения состояния tested реестр публикует событие model_version_ready, позволяющее потребителям подготовить файлы версии. Версия модели может быть опубликована после завершения автоматической проверки и принятия результата пользователем. При публикации svr-models-registry устанавливает признак is_published и обновляет выдаваемый через API перечень опубликованных версий. При запуске реестр также передаёт потребителям актуальный снимок опубликованного каталога событием models_registry_ready. После публикации версия становится доступна LPI-VAP-RS для выбора в логических блоках сценария.

Исполняющее ядро получает уведомления model_version_ready, model_version_updated и model_version_deleted. При необходимости оно запрашивает у реестра метаданные и получает файлы из объектного хранилища в локальный кэш. Фактическая загрузка модели в GPU и обработка кадров происходят только при исполнении сценария, в котором выбрана эта версия.

Массовое обновление версии модели выполняется в следующем порядке:

1. Реестр получает из хранилища сценариев перечень опубликованных версий, использующих выбранную модель, и отображает его пользователю.
2. Пользователь выбирает новую опубликованную версию модели и сценарии для обновления.
3. inf-flows-manager ставит групповую операцию в очередь и последовательно загружает из svr-scenario-storage граф каждого выбранного сценария.
4. Менеджер заменяет значение версии модели в соответствующих логических блоках и возвращает изменённый граф в хранилище сценариев.
5. Для каждого успешно изменённого графа хранилище создаёт новую опубликованную версию сценария и уведомляет смежные компоненты. Состояние групповой операции передаётся веб-интерфейсу через Kafka и WebSocket.

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

3.2. Используемые методы¶

3.3. Структура программы с описанием функций составных частей¶

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

Схема 3.4 — Логическая структура LPI-VAP-MM и внешние связи.

Таблица 3.3.1 — Функции составных частей LPI-VAP-MM.

3.4. Связи программы с другими программами¶

Все служебные соединения выполняются во внутренних сетях развёртывания. Пользователю и внешним клиентам предоставляются только маршруты API-шлюза Платформы 4.0. Прямой внешний доступ к PostgreSQL, MinIO, Kafka, Redis, исполнителям и конвертерам не требуется.

4. Используемые технические средства¶

Компонент эксплуатируется на серверных технических средствах заказчика в составе Платформы 4.0. Выделенные серверы под компонент не требуются: составные части поставляются контейнерными образами и размещаются на узлах уже развёрнутого кластера Kubernetes Платформы 4.0 — тех же, на которых работает Центральный модуль управления данными и распределёнными вычислениями (LPI-VAP-CORE). Установка исполняемых частей компонента на рабочее место пользователя не требуется: работа выполняется через веб-браузер.

Составные части распределяются по типам узлов кластера:

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

Компоненту выделяется доля ресурсов этих узлов, соответствующая позиции поставки LPI-VAP-MM: 8 процессорных ядер, 16 ГБ оперативной памяти, 1000 ГБ дискового пространства и один графический ускоритель класса NVIDIA T4. Состав и назначение выделяемых ресурсов приведены в подразделе 4.3, соотношение с конфигурацией узлов Платформы 4.0 — в п. 4.3.2. Качественные требования, минимально допустимые версии программной среды и удельные величины для расчёта ёмкости приведены в подразделе 4.4 в форме «не ниже».

4.1. Серверные технические средства¶

4.1.1. Размещение составных частей на узлах кластера¶

Таблица 4.1.1 — Размещение составных частей компонента на узлах кластера.

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

4.1.2. Схема развёртывания¶

Схема развёртывания приведена на схеме 4.1. Она показывает размещение составных частей компонента на узлах кластера Платформы 4.0 и внешние связи и не задаёт количество узлов и способ резервирования.

Схема 4.1 — Размещение составных частей компонента на узлах кластера Платформы 4.0.

4.1.3. Требования к техническим средствам узлов¶

Таблица 4.1.2 — Требования к техническим средствам узлов, на которых размещается компонент.

Количественные значения по группам таблицы 4.1.2 установлены подразделом 4.3 (ресурсы, выделяемые компоненту) и таблицей 4.4.1 (требования «не ниже») и в настоящем подразделе не повторяются.

4.1.4. Размещение данных¶

Таблица 4.1.3 — Размещение и защита данных компонента.

4.2. Технические средства рабочего места пользователя¶

Таблица 4.2.1 — Технические средства рабочего места пользователя.

4.3. Ресурсы, выделяемые компоненту¶

Компонент не требует отдельных серверов. Приведённые ниже ресурсы выделяются ему на узлах кластера Платформы 4.0 и соответствуют требованиям к инфраструктуре заказчика для позиции поставки LPI-VAP-MM.

4.3.1. Состав и назначение выделяемых ресурсов¶

Таблица 4.3.1 — Ресурсы, выделяемые компоненту, и их назначение.

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

Таблица 4.3.2 — Минимальные характеристики графического ускорителя.

Дисковое пространство распределяется по классам носителей в соответствии с п. 4.1.4: хранилища метаданных, рабочие каталоги конвертации и кэш моделей — на SSD, пакеты моделей, проверочные данные и результаты запусков — в объектном хранилище на носителях требуемой ёмкости. Общий выделяемый объём при этом не изменяется.

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

4.3.2. Соотношение с конфигурацией узлов Платформы 4.0¶

Узлы, на которых размещается компонент, входят в конфигурацию Платформы 4.0, установленную для позиции поставки LPI-VAP-CORE: мастер-нода и вычислительные ноды с графическими ускорителями. Соотношение ресурсов приведено в таблице 4.3.3.

Таблица 4.3.3 — Ресурсы компонента в составе минимальной конфигурации Платформы 4.0.

Из таблицы 4.3.3 следует:

1. отдельные серверы под компонент не требуются: его составные части размещаются на уже имеющихся мастер-ноде и вычислительной ноде;
2. ресурсы, выделенные компоненту, не участвуют в обеспечении показателей назначения Центрального модуля: занятый конвертацией или проверкой ускоритель на время выполнения задачи не выполняет видеоаналитику, а выделенные процессорные ядра, оперативная память и дисковое пространство не учитываются в расчёте числа обрабатываемых камер;
3. поэтому доля компонента предусматривается сверх минимальной конфигурации узлов либо покрывается запасом ресурсов, заложенным проектом целевой поставки. В целевой конфигурации Центрального модуля из мастер-ноды и четырёх вычислительных нод (104 процессорных ядра, 640 ГБ оперативной памяти, 16 ускорителей класса NVIDIA T4) доля компонента составляет около 8 % процессорных ядер, около 3 % оперативной памяти и один ускоритель из шестнадцати;
4. при совмещении нагрузки без такого запаса производительность видеоаналитики на время конвертации и проверок снижается пропорционально занятым ресурсам; регламент выполнения этих операций (например, вне периодов пиковой нагрузки) устанавливается проектом целевой поставки.

4.3.3. Масштабирование¶

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

Схема 4.2 — Масштабирование контура конвертации и проверочных запусков.

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

4.4. Требования к узлам целевой конфигурации и параметры проектирования¶

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

4.4.1. Требования к узлам по типам¶

Таблица 4.4.1 — Требования к узлам, не нормированные подразделом 4.3.

Число графических ускорителей, выделяемых компоненту, и число вычислительных нод, на которых они размещаются, определяются требуемым параллелизмом конвертаций и проверочных запусков (п. 4.3.3).

4.4.2. Удельные величины для расчёта конфигурации¶

Таблица 4.4.2 — Удельные величины для расчёта конфигурации.

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

4.4.3. Параметры, определяемые проектом поставки¶

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

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

5. Вызов и загрузка¶

Компонент вызывается двумя способами:

• пользователем — из веб-интерфейса Платформы 4.0;
• интеграционным клиентом — через программные интерфейсы Платформы 4.0.

Загрузка серверных составных частей выполняется администратором при запуске Платформы 4.0. Пользователь не запускает исполняемые файлы компонента и не устанавливает их на своё рабочее место. LPI-VAP-CORE выполняет аутентификацию пользователя через СУДИР и формирует пользовательский контекст. После этого браузер загружает клиентское приложение, а оно обращается к реестру моделей, хранилищам проверочных данных и запусков через единый API-шлюз.

5.1. Способ вызова программы¶

5.1.1. Вызов пользователем¶

Порядок вызова компонента пользователем:

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

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

Самостоятельные разделы LPI-VAP-MM относятся к административным функциям. Доступ к ним и к отдельным операциям определяется ролью и полномочиями, переданными LPI-VAP-CORE. Детальное распределение приведено в подразделе 1.3 руководства пользователя. Отсутствие страницы или команды означает, что соответствующее полномочие пользователю не назначено.

Признаками успешного вызова являются:

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

5.1.2. Запуск серверных составных частей¶

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

• узлы кластера подготовлены в соответствии с разделом 4; установлены серверная операционная система, среда исполнения контейнеров, средства оркестрации Kubernetes, драйвер графических ускорителей и средства предоставления ускорителей контейнерам; узлам присвоены признаки назначения (мастер-нода, вычислительная нода);
• контейнерные образы версии поставки загружены на узлы либо доступны в разрешённом реестре образов;
• подготовлены конфигурация развёртывания, секреты, внутренние сети, постоянные тома и области рабочих каталогов; системное время узлов синхронизировано;
• доступны три экземпляра PostgreSQL для метаданных моделей, проверочных данных и запусков, S3-совместимое объектное хранилище и Kafka Платформы 4.0;
• для контура проверочных запусков доступны его Kafka, Redis и рабочие каталоги;
• драйвер NVIDIA, средства предоставления ускорителей контейнерам и графические ускорители доступны менеджеру проверки, конвертерам и исполнителю проверок;
• выполнено согласованное резервное копирование постоянных данных перед запуском новой версии поставки или изменением схем баз данных.

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

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

Таблица 5.1.1 — Порядок загрузки серверных составных частей.

Порядок запуска и остановки приведён на схеме 5.1.

Схема 5.1 — Порядок запуска серверных составных частей (остановка выполняется в обратном порядке).

Для пользователя различаются два уровня готовности:

• готовность каталога — доступны аутентификация, веб-интерфейс, API-шлюз, реестр моделей, его PostgreSQL и объектное хранилище; пользователь может просматривать каталог в пределах назначенных прав;
• полная функциональная готовность — дополнительно доступны хранилища ассетов и запусков, Kafka, Redis, менеджер проверки, исполнители, конвертеры и GPU; разрешены загрузка, конвертация и проверка моделей.

Контейнер со статусом running не является достаточным признаком работоспособности всего компонента. После запуска администратор выполняет проверки из таблицы 5.1.2.

Таблица 5.1.2 — Проверка готовности после загрузки.

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

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

5.2. Входные точки в программу¶

5.2.1. Веб- и программные входные точки¶

Адреса в таблице 5.2.1 задаются относительно внешнего адреса Платформы 4.0. Маршруты с параметрами содержат условные обозначения в угловых скобках.

Таблица 5.2.1 — Входные точки компонента.

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

Прямой внешний доступ пользователей к адресам контейнеров, PostgreSQL, MinIO, Kafka, Redis, Celery и Unix-сокетам конвертеров не предусматривается.

5.2.2. Порядок загрузки пользовательской сессии¶

При открытии раздела выполняются следующие действия:

1. браузер загружает клиентское приложение и эксплуатационную конфигурацию интерфейса;
2. LPI-VAP-CORE проверяет действующую сессию; при её отсутствии или истечении срока действия направляет пользователя на страницу входа СУДИР;
3. после возврата от СУДИР LPI-VAP-CORE формирует пользовательский контекст, а LPI-VAP-MM проверяет переданные разрешения на маршрут и вызываемые операции;
4. клиентское приложение через API-шлюз получает разделы каталога, модели, версии, состояния обработки и справочники типов;
5. интерфейс применяет сохранённые пользовательские параметры отображения, если их сохранение предусмотрено профилем клиентской части, либо использует значения по умолчанию;
6. после получения данных отображаются каталог и доступные команды; состояния длительных операций далее обновляются опросом API или через настроенный канал оперативных уведомлений.

Схема 5.2 — Загрузка пользовательской сессии компонента.

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

5.2.3. Объём программы и использование памяти¶

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

Таблица 5.2.3 — Сведения об объёме программы и использовании памяти.

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

6. Входные данные¶

6.1. Характер и организация входных данных¶

Входные данные компонента образуют пять взаимосвязанных групп:

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

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

Таблица 6.1.1 — Группы входных данных.

Связи основных сущностей показаны на схеме 6.1.

Схема 6.1 — Связи входных сущностей компонента.

6.2. Предварительная подготовка входных данных¶

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

1. Пользователь проходит аутентификацию. Роль должна разрешать требуемую операцию над каталогом моделей, ассетами или проверочными запусками.
2. Для новой модели выбираются существующие значения типа задачи, типа модели и раздела. Наименование модели не должно совпадать с наименованием другой неудалённой модели.
3. Для новой версии задаётся непустое обозначение, отличающее её от других версий той же модели, и подготавливается ZIP-пакет.
4. В корне пакета размещаются model_info.json и coco_categories.json. Путь или шаблон weights_path должен разрешаться в существующий файл весов внутри пакета.
5. JSON-файлы проверяются на синтаксическую корректность, обязательные поля и соответствие типа задачи типу модели. Значения категорий должны совпадать с индексами выходов модели.
6. Формат исходных весов и каждый профиль развёртывания сверяются с составом средств конвертации целевой поставки. Наличие расширения файла само по себе не подтверждает совместимость модели.
7. Для проверки создаётся ассет единого типа image или video. Изображения подготавливаются в JPG или PNG, видеозаписи — в MP4. При необходимости к файлам добавляются зоны с корректными координатами.
8. До постановки задачи проверяются доступность объектного хранилища, очереди сообщений и вычислительных ресурсов, соответствующих профилю модели.

Архив должен иметь следующую минимальную логическую структуру:

<пакет-модели>.zip
├── model_info.json
├── coco_categories.json
├── <файл весов, указанный в weights_path>
└── <дополнительные артефакты, допустимые для типа модели>

Имена utils.py и tasks.py не допускаются в каталоге model/artifacts пользовательской модели. В пакет не следует включать пароли, токены, абсолютные пути файловой системы и данные, не используемые выбранным типом модели.

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

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

6.3. Формат входных данных¶

Таблица 6.3.1 — Форматы входных данных.

ZIP является транспортным контейнером, а не форматом весов. Конкретный файл весов определяется weights_path; после загрузки его пригодность проверяется не по расширению, а средствами выбранного контура исполнения.

6.4. Описание входных данных¶

6.4.1. Пакет модели и метаданные версии¶

Ввод модели разделён на карточку каталога и конкретную версию. Поля карточки приведены в таблице 6.4.1.

Таблица 6.4.1 — Входные поля карточки модели.

Для регистрации версии используются поля таблицы 6.4.2.

Таблица 6.4.2 — Входные поля версии модели.

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

Файл model_info.json связывает пакет с протоколом исполнения.

Таблица 6.4.3 — Основные поля model_info.json.

Для пользовательского типа модели поля task_type, deploy_profile, img_size и weights_path обязательны. Для встроенных типов фактический набор обязательных полей определяется их валидатором, но model_type и согласованный тип задачи должны присутствовать. Каждый заявленный профиль проверяется контрольным инференсом на изображении указанного размера.

Файл coco_categories.json содержит объект с массивом categories. Текущий валидатор ожидает для каждой категории поля таблицы 6.4.4.

Таблица 6.4.4 — Поля категории модели.

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

6.4.2. Наборы проверочных данных и медиафайлы¶

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

Таблица 6.4.5 — Входные данные ассета и его версии.

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

Таблица 6.4.6 — Входные метаданные медиафайла.

Для ограничения области проверки с файлом может быть связано описание зоны.

Таблица 6.4.7 — Входные данные зоны.

Логически полигон задаётся упорядоченным массивом точек [[x1, y1], [x2, y2], ...]. Способ задания координат — в пикселях либо в нормализованных долях размера кадра — должен быть единообразно установлен в спецификации API целевой поставки.

6.4.3. Параметры задач обработки¶

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

Таблица 6.4.8 — Вход автоматической проверки версии модели.

Для повторной проверки передаётся mdl_version_id. Профили конвертации, размер входа и путь к весам извлекаются из зарегистрированного пакета; текущий контракт не позволяет произвольно переопределять их в запросе revalidate.

Проверочный запуск модели на ассете создаётся минимальным набором полей:

Таблица 6.4.9 — Входные параметры проверочного запуска.

После проверки ссылок сервис сам получает модель, тип задачи, список медиафайлов и зоны, формирует UUID запуска и исполнительные сессии. Эти производные данные пользователь не вводит. Для управления задачей передаётся UUID существующего запуска и одна из команд: запуск, повторный запуск или остановка.

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

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

6.4.4. Управляющие и справочные данные¶

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

Таблица 6.4.10 — Управляющие и справочные входные данные.

Сведения об авторе операции — идентификатор пользователя, имя и отображаемое ФИО — добавляются доверенным серверным контекстом. Клиенту не следует использовать эти поля для подмены автора. Даты создания, изменения, публикации и удаления также формируются сервером, если контракт конкретной операции не устанавливает иное.

6.5. Способ кодирования входных данных¶

Структурированные входные данные кодируются по следующим правилам:

• JSON и строковые поля передаются в Unicode, кодировка UTF-8;
• имена полей и строковые значения JSON заключаются в двойные кавычки;
• целые и вещественные числа передаются десятичными цифрами, разделитель дробной части — точка;
• логические значения передаются литералами true и false, отсутствие значения — литералом null;
• идентификаторы записей передаются положительными целыми числами, UUID запусков — строкой канонического представления;
• перечисления передаются установленными машинными значениями с учётом регистра, например image, video, model;
• временные границы фильтров API передаются целым числом секунд от эпохи Unix, если схема конкретного интерфейса не устанавливает формат ISO 8601;
• цвет категории передаётся массивом трёх целых значений от 0 до 255, цвет зоны — строкой #RRGGBB;
• ZIP, веса и медиафайлы передаются как двоичный поток или загружаются по временному подписанному URL; штатная загрузка не требует кодирования файла в Base64;
• внутренние URI, префиксы и имена объектов хранилища формируются сервером из зарегистрированных идентификаторов. Пользователь не должен передавать произвольный путь к объекту вместо предусмотренного файлового поля.

Для сообщений очереди применяется JSON UTF-8 с согласованной схемой события. Изменение имени поля, типа значения или строкового значения перечисления без одновременного обновления отправителя и получателя не допускается.

7. Выходные данные¶

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

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

7.1. Характер и организация выходных данных¶

Выходные данные разделяются на постоянные и оперативные. Карточки моделей, версий, категорий, комментариев и запусков сохраняются в PostgreSQL. Исходные и преобразованные файлы моделей, проверочные данные и результаты запусков размещаются в S3-совместимом объектном хранилище. Состояния проверки и уведомления смежным компонентам передаются через очередь сообщений, а оперативный прогресс — через WebSocket.

Таблица 7.1.1 — Характер и организация выходных данных.

Формирование основных выходов показано на схеме 7.1.

Схема 7.1 — Формирование и передача выходных данных.

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

7.2. Формат выходных данных¶

Таблица 7.2.1 — Форматы выходных данных.

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

7.3. Описание выходных данных¶

7.3.1. Сведения о модели и её версиях¶

Результат создания или получения модели содержит поля таблицы 7.3.1.

Таблица 7.3.1 — Выходные поля карточки модели.

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

Карточка версии модели содержит поля таблицы 7.3.2.

Таблица 7.3.2 — Выходные поля версии модели.

Допустимые технические состояния версии:

Таблица 7.3.3 — Состояния автоматической проверки версии.

Публикация, архивирование и логическое удаление не являются значениями status: они отражаются отдельными полями. Поэтому для принятия решения о доступности версии получатель должен совместно учитывать status, is_tested, is_published и is_archive.

Категория в карточке версии имеет следующие поля:

Таблица 7.3.4 — Выходные поля категории.

Объект file содержит file_id, имя name, размер size в байтах, время загрузки upload_at и системный путь path_to_storage. Системный путь не следует использовать как пользовательскую ссылку: для скачивания выдаётся временный подписанный URI.

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

7.3.2. Результаты конвертации и валидации¶

При обработке версии формируются два вида результата:

1. преобразованные файлы для каждого заявленного и поддерживаемого профиля;
2. состояние проверки с краткой диагностикой.

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

Изменение состояния передаётся между менеджером проверки и реестром объектом:

Таблица 7.3.5 — Результат этапа автоматической проверки.

Для обновления интерфейса реестр формирует оперативное сообщение с полями mdl_version_id, status и error. После успешного контрольного инференса дополнительно публикуется уведомление о готовности версии:

Таблица 7.3.6 — Уведомление о готовности версии.

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

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

7.3.3. Результаты проверки модели на наборе данных¶

Выбранная версия ассета остаётся самостоятельным выходным объектом и входит в состав связи проверочного запуска.

Таблица 7.3.7 — Выходные поля версии проверочного ассета.

Каждая папка содержит идентификатор, наименование и массив media_files. Запись медиафайла включает updfile_id, имя, размер, продолжительность, тип, время загрузки, системный media_uri, необязательный preview_uri и сведения об авторе загрузки.

Проверочный запуск представлен объектом таблицы 7.3.8.

Таблица 7.3.8 — Выходные данные проверочного запуска.

Объект entity_info содержит entity_version_id, entity_name, entity_version, entity_id и task_type. Объект asset содержит asset_name, asset_version, asset_version_id, asset_type и asset_id. Таким образом, результат остаётся связан с точными версиями модели и набора данных даже после появления новых версий.

Оперативное WebSocket-сообщение содержит launch_uuid, progress_percent и необязательное поле error. Постоянный контекст обработки дополнительно содержит текущий файл, его индекс, суммарную длительность и упорядоченный массив media_files.

Таблица 7.3.9 — Результат обработки медиафайла.

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

Файловые результаты организуются по UUID запуска, медиафайлу и номеру кадра:

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

Для модели детекции результат логически содержит категорию объекта, координаты ограничивающей рамки и значение уверенности. Визуализированный кадр предоставляет их человекочитаемое представление. Машинная схема last_message.json и элемента events зависит от типа задачи и протокола конкретной модели; клиент не должен считать дополнительные поля одинаковыми для детекции, классификации и сегментации.

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

7.3.4. Результаты публикации и интеграционного обмена¶

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

Таблица 7.3.11 — Запись опубликованного каталога моделей.

Категория интеграционного каталога содержит id, supercategory, name, ru_name, en_name, признаки is_violation, is_primary, is_active, порог threshold, цвет как объект r/g/b и массив переводов translations.

При удалении версии, готовности версии или изменении отдельного файла передаётся краткая ссылка на сущность с полями mdl_name, mdl_id, version и mdl_version_id. Сообщение об изменении файла дополнительно содержит update_file_name. Получатель после такого уведомления должен запросить или обновить соответствующие данные, а не считать краткое сообщение полной карточкой версии.

Сводка использования модели имеет структуру:

Таблица 7.3.12 — Сведения об использовании версии модели.

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

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

7.3.5. Сообщения о результате и ошибках¶

Синхронная операция возвращает созданный или изменённый объект либо унифицированный ответ с полями status и msg. Файловые операции могут возвращать логическое значение, массив имён файлов или массив подписанных ссылок. Результат постановки повторной проверки содержит mdl_version_id и текстовое сообщение msg.

Таблица 7.3.13 — Сообщения о результате и ошибках.

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

7.4. Способ кодирования выходных данных¶

Для выходных данных применяются следующие правила кодирования:

• структурированные ответы, сообщения очереди и WebSocket кодируются как JSON в UTF-8;
• строки заключаются в двойные кавычки, логические значения передаются литералами true и false, отсутствие значения — литералом null;
• машинные имена полей и значения перечислений передаются с учётом регистра;
• числовые идентификаторы, времена, размеры и счётчики являются целыми числами; при JSON-представлении полей Protobuf типов int64 и uint64 они могут передаваться десятичной строкой для сохранения точности;
• UUID запуска кодируется строкой канонического представления с дефисами;
• время создания, изменения и постановки операции кодируется числом секунд от эпохи Unix;
• процент выполнения кодируется целым числом от 0 до 100, размер файла и суммарный размер результатов — числом байтов;
• состояния версии кодируются строками created, invalid_archive, unpacking_archive, unpack_done, unpack_error, in_validation, failed_validation, in_testing, failed_testing, tested, failed; состояния запуска — processing, completed, failed, stopped;
• координаты и уверенность передаются числами без локализованного форматирования, десятичный разделитель — точка;
• поля color и parameters категории в карточке версии могут содержать сериализованный JSON внутри строки; перед использованием клиент выполняет второй разбор JSON;
• frame_msg и detection_events также содержат экранированный JSON внутри внешнего ответа и разбираются только после успешного получения строки;
• текстовые журналы сохраняются в UTF-8;
• ZIP, веса, преобразованные модели, JPEG и MP4 передаются как двоичные данные либо через подписанный URI; кодирование Base64 штатным способом выдачи не применяется;
• постоянная адресация модели выполняется по идентификатору модели и версии, результата запуска — по UUID, медиафайлу и номеру кадра. Подписанный URI имеет ограниченный срок действия и не сохраняется как постоянная ссылка;
• интеграционные уведомления не должны содержать учётные данные пользователя, секреты доступа к хранилищу и конфиденциальные параметры среды исполнения.

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

Приложения¶

Приложение А (рекомендуемое). Шаблон пакета модели¶

А.1. Структура пакета¶

Минимальная структура ZIP-пакета приведена ниже. Имена файлов model_info.json и coco_categories.json и их размещение в корне архива являются значимыми для загрузчика.

example_model-1.0.0.zip
├── model_info.json
├── coco_categories.json
├── weights/
│   └── model.onnx
└── model/
    └── artifacts/
        └── <дополнительные файлы, требуемые типом модели>

Каталог model/artifacts является условным и включается только тогда, когда это предусмотрено протоколом выбранного типа модели. Файлы с именами utils.py и tasks.py в этом каталоге не допускаются. Путь к весам должен совпадать со значением weights_path.

Перед упаковкой необходимо проверить:

• наличие обоих обязательных JSON-файлов;
• корректность JSON и кодировку UTF-8;
• существование файла, на который указывает weights_path;
• согласованность model_type, task_type и профилей исполнения;
• совпадение идентификаторов категорий с выходами модели;
• отсутствие паролей, токенов и абсолютных путей файловой системы;
• отсутствие лишних копий весов и промежуточных результатов обучения.

А.2. Шаблон model_info.json¶

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

{
  "model_type": "<поддерживаемый тип модели>",
  "task_type": "<согласованный тип задачи>",
  "model_name": "example_model",
  "model_version": "1.0.0",
  "img_size": {
    "height": 640,
    "width": 640
  },
  "weights_path": "weights/model.onnx",
  "categories_path": "coco_categories.json",
  "deploy_profile": {
    "default_profile": "<профиль исполнения>",
    "profiles": [
      "<профиль исполнения>"
    ]
  },
  "model_attributes": {
    "confidence_threshold": {
      "type": "float",
      "default": 0.5,
      "ru_name": "Порог уверенности"
    }
  }
}

Если используется пользовательский тип модели, поля task_type, deploy_profile, img_size и weights_path обязательны. Для встроенного типа окончательный набор полей определяется валидатором этого типа.

А.3. Шаблон coco_categories.json¶

{
  "categories": [
    {
      "id": 1,
      "name": "example_object",
      "ru_name": "Объект",
      "full_ru_name": "Пример распознаваемого объекта",
      "supercategory": "object",
      "threshold": 0.5,
      "color": [0, 255, 0],
      "is_violation": false,
      "is_primary": true,
      "exclude": false
    }
  ]
}

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

Приложение Б (справочное). Жизненный цикл версии модели¶

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

Схема Б.1 — Жизненный цикл автоматической проверки версии модели.

Краткие сообщения обмена имеют следующие структуры.

Событие, запускающее проверку:

{
  "mdl_name": "example_model",
  "mdl_id": 10,
  "version": "1.0.0",
  "mdl_version_id": 123
}

Сообщение о состоянии проверки:

{
  "mdl_version_id": 123,
  "status": "in_validation",
  "error_msg": ""
}

Сообщение об ошибке, предназначенное для интерфейса:

{
  "mdl_version_id": 123,
  "status": "failed_validation",
  "error": "Не найден файл весов, указанный в weights_path"
}

Уведомление о готовности версии:

{
  "mdl_name": "example_model",
  "mdl_id": 10,
  "version": "1.0.0",
  "mdl_version_id": 123
}

Примеры показывают логический состав сообщений. Числовые поля int64 при передаче в JSON через прикладной Protobuf-интерфейс могут быть представлены десятичными строками.

Приложение В (справочное). Результаты проверочного запуска¶

В.1. Организация файлов¶

Результаты группируются по UUID запуска, исходному медиафайлу и номеру кадра. Конкретное техническое имя каталога медиафайла формируется системой.

<launch_uuid>/
└── <media>/
    ├── log.txt
    ├── events.json
    └── frames/
        ├── 000000/
        │   ├── image.jpg
        │   ├── image_vis.jpg
        │   ├── last_message.json
        │   └── last_execution_log.txt
        └── <следующий кадр>/
            └── ...

Для проверки одного изображения используется результат кадра 000000. Для видео число каталогов зависит от длительности файла и шага обработки кадров.

Таблица В.1 — Соответствие операций выдаваемым артефактам.

В.2. Сообщение прогресса¶

{
  "launch_uuid": "00000000-0000-0000-0000-000000000001",
  "progress_percent": 75,
  "error": ""
}

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

В.3. Логическое представление обнаружения¶

Ниже приведён иллюстративный, а не нормативный пример. Точные имена полей events.json определяются типом задачи и протоколом модели.

{
  "events": [
    {
      "category_id": 1,
      "category_name": "example_object",
      "confidence": 0.91,
      "bbox": {
        "min_x": 120,
        "min_y": 80,
        "max_x": 420,
        "max_y": 560
      }
    }
  ]
}

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

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

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

Таблица Г.1 — Сведения, уточняемые для целевой поставки.

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

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

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

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

MM-MER-001. Схема 1.1 — Место LPI-VAP-MM в Платформе 4.0¶

Расположение схемы: 1.1. Обозначение и наименование программы.

flowchart TB
    UI["Веб-интерфейс<br/>Платформы 4.0"]
    subgraph MM["LPI-VAP-MM"]
        direction TB
        CAT["Каталог моделей<br/>и версий"]
        CHECK["Конвертация<br/>и автоматическая проверка"]
        ASSET["Проверочные данные"]
        RUN["Проверочные запуски<br/>и результаты"]
        CAT --> CHECK
        CHECK --> CAT
        ASSET --> RUN
        CAT --> RUN
        RUN --> CAT
    end
    UI --> CAT
    UI --> ASSET
    UI --> RUN
    CORE["LPI-VAP-CORE<br/>доступ, камеры"] <--> CAT
    CAT --> RS["LPI-VAP-RS<br/>сценарии"]
    CAT --> INF["Исполняющее ядро<br/>видеоаналитики"]

MM-MER-002. Схема 1.2 — Уровни программного обеспечения, необходимого для функционирования компонента¶

Расположение схемы: 1.2. Программное обеспечение, необходимое для функционирования программы.

flowchart TB
    L1["Уровень 1. Технические средства узлов кластера<br/>серверы x86-64, графические ускорители, накопители, сеть<br/>(раздел 4)"]
    L2["Уровень 2. Системное программное обеспечение<br/>«Московская серверная операционная система», среда исполнения контейнеров,<br/>Kubernetes, драйвер NVIDIA и средства предоставления ускорителей, CUDA, cuDNN, TensorRT<br/>(п. 1.2.1)"]
    L3["Уровень 3. Общесистемные сервисы Платформы 4.0<br/>PostgreSQL, MinIO, Apache Kafka, Redis, nginx и веб-шлюз<br/>(п. 1.2.2)"]
    L4["Уровень 4. Среды исполнения и библиотеки<br/>Python, Node.js, FastAPI, Celery, PyTorch, ONNX, OpenCV и другие<br/>(п. 1.2.3)"]
    L5["Уровень 5. Составные части LPI-VAP-MM<br/>реестр моделей, хранилища проверочных данных и запусков,<br/>менеджер проверки, исполнитель проверок и конвертеры<br/>(п. 1.1, подраздел 3.3)"]
    L6["Уровень 6. Клиентское программное обеспечение<br/>веб-браузер рабочего места пользователя<br/>(п. 1.2.5)"]
    EXTC["Смежные компоненты и внешние средства<br/>LPI-VAP-CORE (единая точка входа через СУДИР),<br/>LPI-VAP-RS и исполняющее ядро видеоаналитики<br/>(п. 1.2.4)"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6
    L5 <--> EXTC

MM-MER-003. Схема 2.1 — Функциональный цикл подготовки версии модели¶

Расположение схемы: 2.1. Классы решаемых задач.

flowchart TB
    ZIP["ZIP-пакет модели"] --> VER["Создание версии<br/>и регистрация метаданных"]
    VER --> CHECK["Проверка целостности,<br/>валидация и конвертация"]
    CHECK -->|ошибка| FIX["Исправление пакета<br/>или метаданных"]
    FIX --> VER
    CHECK -->|успешно| TEST["Проверка на версии<br/>набора данных"]
    ASSET["JPG, PNG, MP4<br/>и описания зон"] --> TEST
    TEST -->|результат не принят| FIX
    TEST -->|результат принят| PUB["Публикация версии"]
    PUB --> RS["Выбор модели<br/>в сценариях"]
    RS --> INF["Исполнение на видеопотоках<br/>смежным компонентом"]

MM-MER-004. Схема 3.1 — Загрузка пакета и создание версии модели¶

Расположение схемы: 3.1.1. Загрузка модели и создание версии.

sequenceDiagram
    actor U as Пользователь
    participant UI as Веб-интерфейс
    participant MR as svr-models-registry
    participant DB as PostgreSQL
    participant S3 as MinIO
    participant K as Kafka Платформы 4.0

    U->>UI: Создать модель или версию
    UI->>MR: Метаданные модели и версии
    MR->>DB: Создать записи каталога
    alt Загрузка пакета
        U->>UI: Передать ZIP-пакет
        UI->>MR: Поток файла
        MR->>S3: Сохранить и извлечь архив
        MR->>S3: Прочитать model_info.json и категории
        MR->>DB: Сохранить файлы, категории и unpack_done
        alt Выбрано «Сохранить и валидировать»
            MR->>K: model_version_uploaded
        else Версия сохранена как черновик
            MR-->>UI: Состояние unpack_done
        end
    else Копирование последней версии
        UI->>MR: CreateCloneModelVersionFromLastModel
        MR->>DB: Создать новую версию
        MR->>S3: Подготовить артефакты новой версии
    end
    MR-->>UI: Идентификатор и состояние версии

MM-MER-005. Схема 3.2 — Конвертация и автоматическая проверка версии модели¶

Расположение схемы: 3.1.2. Конвертация и валидация модели.

flowchart TD
    EVT["model_version_uploaded"] --> LOAD["Загрузка файлов<br/>из реестра"]
    LOAD --> CONV["Конвертация всех<br/>требуемых профилей"]
    CONV -->|ошибка| FC["failed"]
    CONV --> VAL["Проверка файлов<br/>и метаданных"]
    VAL -->|ошибка| FV["failed"]
    VAL --> TEST["Контрольный<br/>инференс"]
    TEST -->|ошибка| FT["failed"]
    TEST -->|успешно| OK["tested"]
    FC --> STATUS["Сохранение состояния<br/>и диагностического сообщения"]
    FV --> STATUS
    FT --> STATUS
    OK --> STATUS

MM-MER-006. Схема 3.3 — Проверка модели на версии ассета¶

Расположение схемы: 3.1.3. Проверка модели на наборе данных.

sequenceDiagram
    actor U as Пользователь
    participant UI as Веб-интерфейс
    participant LS as svr-launch-storage
    participant MR as svr-models-registry
    participant AS as svr-asset-storage
    participant SB as nr-sbx-backend
    participant CW as nr-sbx-celery
    participant S3 as MinIO
    participant KS as Kafka контура проверки
    participant K as Kafka Платформы 4.0

    U->>UI: Запустить проверку модели на ассете
    UI->>LS: StartLaunch(model_version, asset_version)
    LS->>MR: GetModelVersion
    LS->>AS: GetAssetVersion
    LS->>SB: start_launch_session
    SB->>CW: process_session
    loop Для каждого медиафайла
        CW->>KS: Прогресс обработки
        KS-->>SB: Состояние и результат задачи
        SB->>S3: Результаты, кадры и журналы
        SB->>K: change_launch_status
        K-->>LS: Состояние запуска
        opt Есть следующий файл
            LS->>K: continue_launch
            K-->>SB: Продолжить запуск
        end
    end
    LS-->>UI: completed или failed
    UI->>LS: Запрос кадров и результатов
    LS->>S3: Чтение артефактов
    LS-->>UI: Данные визуализации

MM-MER-007. Схема 3.4 — Логическая структура LPI-VAP-MM и внешние связи¶

Расположение схемы: 3.3. Структура программы с описанием функций составных частей.

flowchart TB
    UI["Веб-интерфейс Платформы 4.0"] --> GW["API-шлюз"]

    subgraph MM["LPI-VAP-MM — управление моделями"]
        MR["svr-models-registry<br/>каталог и версии"]
        AS["svr-asset-storage<br/>проверочные данные"]
        LS["svr-launch-storage<br/>запуски и результаты"]
        FM["inf-flows-manager<br/>валидация и обновление сценариев"]
        CONV["yolo-conversion / mm-conversion"]
        SB["nr-sbx-backend<br/>сессии проверки"]
        CEL["nr-sbx-celery<br/>исполнение на ассетах"]
        SCONV["nr-sbx-*-conversion"]
    end

    GW --> MR
    GW --> AS
    GW --> LS
    GW --> FM
    MR --> DBM[("PostgreSQL<br/>модели")]
    AS --> DBA[("PostgreSQL<br/>ассеты")]
    LS --> DBL[("PostgreSQL<br/>запуски")]
    MR --> S3[("MinIO")]
    AS --> S3
    LS --> S3
    MR <--> K["Kafka Платформы 4.0"]
    KS["Kafka контура проверки"]
    K --> FM
    FM --> CONV
    FM --> MR
    LS --> SB
    SB --> R["Redis"]
    SB --> CEL
    CEL --> SCONV
    CEL --> KS
    KS --> SB
    SB --> S3
    SB <--> K
    FM --> SS["LPI-VAP-RS<br/>хранилище сценариев"]
    MR --> SS
    K --> INF["Исполняющее ядро<br/>видеоаналитики"]
    INF --> MR
    INF --> S3

MM-MER-008. Схема 4.1 — Размещение составных частей компонента на узлах кластера Платформы 4.0¶

Расположение схемы: 4.1.2. Схема развёртывания.

flowchart TB
    USERS["Рабочие места<br/>пользователей"]
    SUDIR["СУДИР"]
    CORE["LPI-VAP-CORE<br/>единая точка входа<br/>и пользовательский контекст"]

    subgraph MASTER["Мастер-нода кластера Платформы 4.0"]
        direction TB
        GW["Веб-интерфейс и шлюз API<br/>(Платформа 4.0)"]
        APPS["Составные части LPI-VAP-MM:<br/>реестр моделей, проверочные<br/>данные, запуски"]
        DATA[("Общесистемные средства Платформы 4.0:<br/>PostgreSQL, объектное хранилище,<br/>брокер сообщений и очередь задач")]
        GW --> APPS --> DATA
    end

    subgraph COMPUTE["Вычислительная нода кластера (GPU)"]
        direction TB
        FM["Составные части LPI-VAP-MM:<br/>менеджер проверки и конвертеры"]
        RUN["Исполнитель<br/>проверочных запусков"]
        CACHE["Рабочие каталоги<br/>и кэш моделей"]
        NRI["Видеоаналитика LPI-VAP-CORE<br/>(остальные ускорители ноды)"]
        FM --> RUN --> CACHE
    end

    EXTC["Смежные компоненты:<br/>LPI-VAP-RS и исполняющее<br/>ядро видеоаналитики"]
    BACKUP["Резервное<br/>копирование"]

    USERS --> CORE
    SUDIR <--> CORE
    CORE --> GW
    APPS --> FM
    FM --> DATA
    RUN --> DATA
    APPS <--> EXTC
    DATA --> BACKUP

MM-MER-009. Схема 4.2 — Масштабирование контура конвертации и проверочных запусков¶

Расположение схемы: 4.3.3. Масштабирование.

flowchart TB
    N1["1 ускоритель<br/>1 задача конвертации или проверки<br/>одновременно"]
    N2["2 ускорителя<br/>2 задачи одновременно"]
    N4["4 ускорителя<br/>4 задачи одновременно"]
    NX["Дальнейшее масштабирование<br/>пропорционально числу<br/>выделенных ускорителей"]
    MASTER["Ресурсы мастер-ноды:<br/>рассчитываются по числу моделей и версий,<br/>объёму проверочных данных и результатов<br/>и срокам их хранения"]

    N1 --> N2 --> N4 --> NX
    MASTER -.-> N1

MM-MER-010. Схема 5.1 — Порядок запуска серверных составных частей (остановка выполняется в обратном порядке)¶

Расположение схемы: 5.1.2. Запуск серверных составных частей.

flowchart TB
    G1["1. Базовая инфраструктура узлов<br/>среда исполнения контейнеров и Kubernetes,<br/>сети, тома, графические ускорители"]
    G2["2. Хранение и обмен<br/>PostgreSQL, объектное хранилище,<br/>брокеры сообщений и очередь задач"]
    G3["3. Прикладные хранилища<br/>реестр моделей, проверочные данные, запуски"]
    G4["4. Автоматическая обработка<br/>менеджер проверки и конвертеры"]
    G5["5. Контур пользовательских проверок<br/>прикладной сервис, очередь, исполнитель"]
    G6["6. Внешний доступ<br/>веб-интерфейс и шлюз прикладных интерфейсов"]
    CHK{"Проверка готовности<br/>группы пройдена?"}
    RST["Перезапуск сервиса средствами оркестратора;<br/>запуск следующих групп приостановлен"]
    OK["Компонент готов к работе"]

    G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> CHK
    CHK -->|нет| RST
    RST --> CHK
    CHK -->|да| OK

MM-MER-011. Схема 5.2 — Загрузка пользовательской сессии компонента¶

Расположение схемы: 5.2.2. Порядок загрузки пользовательской сессии.

sequenceDiagram
    actor U as Пользователь
    participant UI as Веб-интерфейс
    participant CORE as LPI-VAP-CORE<br/>единая точка входа
    participant GW as API-шлюз
    participant MR as Реестр моделей
    participant ST as Хранилища ассетов и запусков

    U->>UI: Открыть раздел «Модели»
    UI->>CORE: Проверить сессию и разрешения
    alt Сессия отсутствует или истекла
        CORE-->>UI: Требуется вход через СУДИР
        UI-->>U: Страница входа
    else Сессия действительна
        UI->>GW: Запрос каталога и справочников
        GW->>MR: Получить модели и версии
        MR-->>GW: Каталог и состояния
        GW->>ST: Получить связанные проверки
        ST-->>GW: Состояния и результаты
        GW-->>UI: Данные раздела
        UI-->>U: Каталог и доступные команды
    end

MM-MER-012. Схема 6.1 — Связи входных сущностей компонента¶

Расположение схемы: 6.1. Характер и организация входных данных.

flowchart TB
    REF["Справочники типов,<br/>разделов и категорий"] --> M["Карточка модели"]
    M --> MV["Версия модели"]
    PKG["ZIP-пакет модели"] --> MV
    REF --> MV
    MEDIA["JPG, PNG, MP4<br/>и описания зон"] --> AV["Версия набора данных"]
    A["Карточка набора<br/>проверочных данных"] --> AV
    MV --> L["Проверочный запуск"]
    AV --> L
    MV --> S["Сценарии,<br/>использующие версию"]

MM-MER-013. Схема 7.1 — Формирование и передача выходных данных¶

Расположение схемы: 7.1. Характер и организация выходных данных.

flowchart TB
    PKG["Пакет модели"] --> MR["Реестр моделей"]
    MR --> DB[("Метаданные моделей<br/>и версий")]
    MR --> S3[("Файлы модели<br/>и артефакты")]
    MR --> VERIFY["Конвертация,<br/>валидация и тест"]
    VERIFY --> S3
    VERIFY --> STATUS["Состояние<br/>и диагностика"]
    MV["Версия модели"] --> RUN["Проверочный запуск"]
    AV["Версия набора данных"] --> RUN
    RUN --> PROGRESS["Состояние и прогресс"]
    RUN --> RESULT["Кадры, обнаружения<br/>и журналы"]
    DB --> UI["Веб-интерфейс<br/>Платформы 4.0"]
    STATUS --> UI
    PROGRESS --> UI
    RESULT --> UI
    MR -->|"опубликованный<br/>каталог"| RS["Сценарии<br/>и исполняющие компоненты"]

MM-MER-014. Схема Б.1 — Жизненный цикл автоматической проверки версии модели¶

Расположение схемы: Приложение Б (справочное). Жизненный цикл версии модели.

flowchart TB
    NEW(["Создание версии"]) --> CREATED["created"]
    CREATED -->|"архив не прошёл<br/>базовую проверку"| INVALID["invalid_archive"]
    CREATED -->|"архив принят"| UNPACKING["unpacking_archive"]
    UNPACKING -->|"распаковка успешна"| UNPACKED["unpack_done"]
    UNPACKING -->|"ошибка распаковки"| UNPACK_ERROR["unpack_error"]
    INVALID -->|"повторная загрузка"| UNPACKING
    UNPACK_ERROR -->|"повторная загрузка"| UNPACKING
    UNPACKED -->|"сохранить и валидировать"| VALIDATION["in_validation"]
    VALIDATION -->|"конвертация и<br/>валидация успешны"| TESTING["in_testing"]
    VALIDATION -->|"ошибка этапа"| FAILED_VALIDATION["failed_validation"]
    TESTING -->|"контрольный инференс<br/>успешен"| TESTED["tested"]
    TESTING -->|"ошибка этапа"| FAILED_TESTING["failed_testing"]
    VALIDATION -->|"иная ошибка"| FAILED["failed"]
    TESTING -->|"иная ошибка"| FAILED
    FAILED_VALIDATION -->|"повторная проверка"| VALIDATION
    FAILED_TESTING -->|"повторная проверка"| VALIDATION
    FAILED -->|"повторная проверка"| VALIDATION
    TESTED -->|"повторная проверка"| VALIDATION

    TESTED -.-> FLAGS["Отдельные признаки:<br/>is_tested, is_published,<br/>is_archive"]

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

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

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

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

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