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

Полное наименование: Компонент среды разработки сценариев видеоаналитики

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

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

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

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

Аннотация¶

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

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

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

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

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

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

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

Компонент предназначен для визуальной разработки сценариев видеоаналитики в форматах low-code (соединение готовых логических блоков в алгоритм) и no-code (настройка атрибутов существующих блоков), версионного хранения сценариев и отладки версии сценария на проверочных файлах. Опубликованная версия сценария преобразуется в исполняемое представление, применяемое затем при обработке видеопотоков камер. Классы решаемых задач и границы функциональной ответственности компонента приведены в разделе 2.

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

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

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

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

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

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

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

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

Визуальный редактор, прикладной API среды и хранилища сценариев, запусков и проверочных данных исполняются на процессорах мастер-ноды. Графический ускоритель требуется вычислительной ноде, выполняющей отладочные запуски и конвертацию моделей; для компонента должен быть предусмотрен как минимум один ускоритель класса NVIDIA T4. Конкретная модель ускорителя и совместимые версии драйвера и CUDA уточняются в спецификации целевой поставки. Требования к техническим средствам приведены в разделе 4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1. Создание, сохранение и публикация сценария¶

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

1. Пользователь создаёт сценарий и неопубликованную версию либо выбирает существующую рабочую версию.
2. Бэкенд песочницы создаёт сессию редактирования. Для сессии формируется отдельный рабочий каталог и запускается экземпляр визуального редактора.
3. Если версия уже содержит граф, бэкенд получает его из хранилища сценариев и загружает в редактор. Для новой версии создаётся пустой граф с корневой вкладкой сценария.
4. Редактор формирует палитру из разрешённых стандартных и пользовательских блоков. Параметры моделей, зон и нарушений берутся из синхронизированных конфигураций блоков.
5. Пользователь добавляет блоки, задаёт их параметры и соединяет входы и выходы. Редактор сохраняет результат в сессионный файл flows.json.
6. При сохранении бэкенд получает flows.json, передаёт его сервису обработки графов для извлечения параметров и записывает в хранилище сценариев: граф, настройки блоков, идентификатор вкладки и перечень используемых моделей с версиями.
7. После сохранения графа версия может быть опубликована. Хранилище изменяет состояние версии и передаёт через Kafka перечень опубликованных версий и актуальные настройки сценариев смежным компонентам.
8. Сессия редактора закрывается; временный каталог и процесс редактора освобождаются.

Последовательность показана на схеме 3.1.

Схема 3.1 — Создание и публикация версии сценария.

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

3.1.2. Отладочный запуск¶

Отладка выполняется для конкретной версии сценария и выбранной версии набора проверочных данных:

1. Хранилище запусков получает идентификаторы версии сценария и версии ассета.
2. Из хранилищ сценариев и ассетов запрашиваются метаданные, граф, ссылки на медиафайлы и описания зон.
3. Создаётся запись запуска с уникальным идентификатором и контекст обработки медиафайлов.
4. Бэкенд песочницы создаёт исполнительную сессию, помещает в неё flows.json, подключает проверочные данные и передаёт задачу исполнителю.
5. Исполнитель обрабатывает изображения или кадры видео согласно графу. Для каждого кадра сохраняются исходное и визуализированное изображения, результирующее сообщение и журнал выполнения; для медиафайла сохраняются общий журнал и сформированные события.
6. Исполнитель передаёт статусы через Kafka. Хранилище запусков обновляет состояние, размер результатов и процент выполнения и публикует прогресс для веб-интерфейса.
7. Набор изображений обрабатывается в рамках одной сессии. Если ассет содержит несколько видео, они обрабатываются последовательно; после завершения одного файла хранилище запусков передаёт исполнителю следующий.
8. После обработки всех файлов прогресс устанавливается в 100 %, исполнительная сессия закрывается, а результаты остаются доступными для просмотра.

Схема 3.2 — Выполнение отладочного запуска.

3.1.3. Выполнение графа¶

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

Блоки выполняют четыре основные группы операций:

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

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

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

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

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

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

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

Связи основных составных частей показаны на схеме 3.3.

Схема 3.3 — Логическая структура компонента и его окружение.

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

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

Обмен структурированными данными выполняется в кодировке UTF-8. Графы, REST-сообщения и события Kafka передаются в JSON; медиафайлы загружаются через подписанные ссылки объектного хранилища. Идентификаторы сценария, его версии, вкладки графа, ассета и запуска используются совместно для сохранения трассируемости между этапами разработки и отладки.

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

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

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

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

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

Компоненту выделяется доля ресурсов этих узлов, соответствующая позиции поставки LPI-VAP-RS: 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; компонент использует в них собственные базы данных, бакеты и топики. Размещение задаётся признаками узлов и правилами планирования Kubernetes; на вычислительной ноде графический ускоритель предоставляется рабочим нагрузкам как ресурс nvidia.com/gpu, и один ускоритель не используется одновременно отладочным запуском и рабочей видеоаналитикой LPI-VAP-CORE. При развёртывании на одном сервере назначения мастер-ноды и вычислительной ноды совмещаются; требуемые ресурсы при этом не изменяются.

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

Схема 4.1 — Размещение составных частей LPI-VAP-RS в Kubernetes.

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-RS.

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

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

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

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

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

Приведённые значения соответствуют одному параллельному отладочному запуску или конвертации и штатному числу одновременных сессий редактора по подразделу 2.3. Они не включают ресурсы общесистемных средств Платформы 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. при совмещении нагрузки без такого запаса производительность видеоаналитики на время отладочных запусков и конвертаций снижается пропорционально занятым ресурсам; запросы и пределы ресурсов Kubernetes должны исключать вытеснение рабочих нагрузок Центрального модуля, а регламент выполнения отладки (например, вне периодов пиковой нагрузки) устанавливается проектом целевой поставки.

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. запустить поддерживаемый веб-браузер;
2. открыть внешний адрес Платформы 4.0, установленный для целевой поставки;
3. пройти единый вход: LPI-VAP-CORE перенаправляет пользователя в СУДИР, после успешного возврата проверяет групповое право и формирует пользовательский контекст с ролью и полномочиями;
4. открыть доступный для назначенной роли раздел управления сценариями;
5. выбрать сценарий и его версию, после чего вызвать редактирование либо отладочный запуск соответствующей командой интерфейса.

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

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

Схема 5.1 — Вызов редактора сценария пользователем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внешний доступ следует публиковать через web-шлюз Платформы 4.0. Прямой доступ пользователей к внутренним адресам контейнеров, PostgreSQL, Redis, Kafka, объектному хранилищу и Unix-сокетам конвертеров не предусматривается. Перечень внешних REST API, разрешённых для интеграционных клиентов, их полный базовый путь и способ аутентификации определяются спецификацией API целевой поставки в соответствии с приложением Г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связи основных входных наборов показаны на схеме 6.1.

Схема 6.1 — Формирование входных данных отладочного запуска

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

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

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

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

Для подготовки данных отладки необходимо:

1. Создать ассет требуемого типа — «изображения» или «видео» — и его рабочую версию. Медиафайлы разных типов не следует объединять в одной версии ассета.
2. Загрузить файлы JPG или PNG для ассета изображений либо файлы MP4 для видеоассета. Загруженный видеофайл должен открываться установленными в компоненте средствами декодирования: после загрузки система читает его длительность и формирует кадр предварительного просмотра.
3. При необходимости задать зоны отдельно для каждого медиафайла. Полигон должен содержать числовые координаты точек, а тип зоны должен присутствовать в справочнике. Координаты должны соответствовать системе координат исходного изображения или кадров видео.
4. Убедиться, что требуемые графом модели и их исполняемые веса доступны отладочному исполнителю.
5. Выбрать совместимые версии сценария и ассета. При запуске передаются именно их идентификаторы; файлы, зоны и UUID вкладки сценария разрешаются серверной частью автоматически.

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

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

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

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

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

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

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

6.4.1. Сценарий и версия¶

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

Таблица 6.4.1 — Входные данные сценария и версии

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

6.4.2. Граф и настройки блоков¶

flow_data содержит JSON-массив объектов Node-RED. Общие поля объектов приведены в таблице 6.4.2. Набор специальных параметров зависит от типа блока и его конфигурации, поэтому неизвестные универсальной схеме поля сохраняются в составе объекта блока.

Таблица 6.4.2 — Общие поля объекта графа

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

Таблица 6.4.3 — Поля настроек блоков

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

6.4.3. Проверочные данные и зоны¶

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

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

6.4.4. Отладочный запуск¶

Минимальный запрос на создание отладочного запуска содержит:

Таблица 6.4.5 — Входные данные создания отладочного запуска

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

Команда покадровой работы дополнительно может содержать имя видео, номер кадра — целое число от нуля — и признак выдачи визуализированного кадра. Команда запуска графа содержит идентификатор сессии и объект выбранной вкладки с полями id, name и type.

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

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

• текст JSON и строковые поля передаются в Unicode, кодировка UTF-8;
• объект JSON заключается в фигурные скобки, массив — в квадратные; имена полей и строковые значения заключаются в двойные кавычки;
• целые и вещественные числа передаются десятичными цифрами, разделитель дробной части — точка;
• логические значения передаются литералами true и false, отсутствие значения — литералом null;
• перечисления передаются строковыми машинными значениями с учётом регистра, например scenario, image, video, frame_scenario;
• числовые идентификаторы сценариев, версий, файлов и сессий кодируются десятичными целыми числами без разделителей;
• идентификатор запуска кодируется строкой UUID с дефисами; идентификатор вкладки и блока Node-RED передаётся строкой без преобразования;
• время создания, изменения и границы фильтра передаются как целое число секунд с начала эпохи Unix; значения времени формируются серверной частью;
• геометрия зон кодируется вложенными JSON-массивами числовых координат, цвет — строкой #RRGGBB;
• изображения и видео передаются как исходная последовательность байтов файла с соответствующим MIME-типом и не включаются в JSON в виде Base64;
• подписанный URI используется только в течение срока его действия; постоянная связь обеспечивается системными идентификаторами ассета, версии и файла.

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

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

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

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

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

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

Выходные данные разделяются на постоянные и оперативные. Метаданные сценариев, версий и запусков сохраняются в PostgreSQL. Графы и извлечённые настройки хранятся совместно с соответствующей версией сценария. Файловые результаты отладки размещаются в S3-совместимом объектном хранилище, а пользователю передаются их метаданные или временные подписанные ссылки. Оперативный прогресс и ошибки передаются в веб-интерфейс через WebSocket.

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

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

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

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

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

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

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

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

7.3.1. Результаты сохранения и публикации версии сценария¶

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

Таблица 7.3.1 — Выходные данные версии сценария

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

Таблица 7.3.2 — Сведения об опубликованной версии

При изменении параметров отдельно передаётся объект со следующими полями: scenario_id, scenario_version_id и settings. Поле settings содержит описанную в таблице 6.4.3 структуру настроек блоков. Полный граф загружается смежным компонентом по UUID версии через внутренний программный интерфейс.

7.3.2. Сведения об отладочном запуске¶

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

Таблица 7.3.3 — Выходные данные отладочного запуска

Оперативное сообщение общего прогресса содержит launch_uuid, progress_percent, size и необязательное поле error. Детализированное сообщение исполнительной сессии содержит:

Таблица 7.3.4 — Оперативные данные выполнения

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

7.3.3. Контекст обработки медиафайлов¶

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

Таблица 7.3.5 — Контекст обработки медиафайлов

Каждый элемент media_files содержит:

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

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

7.3.4. Файловые результаты отладки¶

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

Таблица 7.3.7 — Файловые результаты отладки

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

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

Успешные команды создания и остановки исполнительной задачи возвращают текстовое сообщение и строковый идентификатор задачи task_id. Результат создания редакторской сессии содержит session_id и node_red_url; результат создания исполнительной сессии запуска — launch_uuid и session_id.

Ошибка проверки HTTP-запроса возвращается как JSON с описанием в поле detail. Ошибка асинхронного исполнения передаётся в WebSocket-сообщении с полями session_id, error и message либо в поле error сообщения прогресса запуска. Серверная трассировка стека, внутренние адреса и конфиденциальные параметры не должны передаваться штатному пользователю; они записываются в защищённый технический журнал.

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

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

• структурированные ответы, сообщения Kafka и WebSocket кодируются как JSON в UTF-8;
• имена полей и машинные значения перечислений передаются с учётом регистра;
• строки JSON заключаются в двойные кавычки, числа передаются десятичными цифрами, логические значения — литералами true и false, отсутствие значения — литералом null;
• идентификаторы сценариев, версий, файлов, сессий, задач и сообщений передаются без локализованного форматирования; числовые идентификаторы — целыми числами, UUID запуска — строкой с дефисами;
• время создания и изменения кодируется целым числом секунд с начала эпохи Unix;
• процент выполнения кодируется целым числом от 0 до 100, объём артефактов — целым числом байтов;
• значения состояний кодируются строками created, running, failed, completed, stopped, а состояния файлов — pending, processing, completed;
• текстовые журналы сохраняются и передаются в UTF-8; недекодируемые байты при чтении заменяются служебным символом замены Unicode;
• last_message.json и events.json являются JSON-файлами, но отдельные программные интерфейсы возвращают их содержимое как экранированную строку внутри внешнего JSON-ответа; клиент должен выполнить разбор этой строки как JSON только после успешного получения ответа;
• изображения image.jpg и image_vis.jpg кодируются в JPEG и передаются как двоичные данные либо через подписанную ссылку; кодирование Base64 не применяется;
• визуализированная видеозапись, если она сформирована, кодируется в контейнере MP4 и передаётся как двоичный файл;
• постоянная адресация результата выполняется по UUID запуска, идентификатору файла и номеру кадра; подписанный URI является временным транспортным представлением;
• сообщения об опубликованных версиях содержат только технические идентификаторы, наименования, версии и зависимости сценария и не должны содержать учётные данные пользователя.

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

Приложения¶

Приложение А (рекомендуемое). Контрольный состав версии сценария¶

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

Таблица А.1 — Контрольный состав версии сценария.

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

Схема А.1 — Пример логической последовательности блоков сценария.

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

Схема Б.1 — Рекомендуемый жизненный цикл версии сценария.

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

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

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

В.1. Состояния запуска и медиафайлов¶

Таблица В.1 — Состояния отладочного запуска и медиафайлов.

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

В.2. Уровни результатов¶

Таблица В.2 — Уровни результатов отладочного запуска.

Рекомендуемый порядок анализа результата:

1. сопоставить UUID запуска с выбранными версиями сценария и ассета;
2. проверить состояние запуска и достижение ожидаемого процента выполнения;
3. проверить состояние каждого медиафайла и наличие общего журнала;
4. просмотреть исходные и визуализированные кадры на контрольных шагах;
5. сопоставить last_message.json, покадровый журнал и events.json с ожидаемой логикой сценария;
6. зафиксировать результат проверки и замечания по правилам проекта.

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

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

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

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

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

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

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

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

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

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

RS-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, Node-RED, FastAPI, Celery, PyTorch, vlmodels, OpenCV и другие<br/>(п. 1.2.3)"]
    L5["Уровень 5. Составные части LPI-VAP-RS<br/>визуальный редактор, прикладной API среды, хранилища сценариев,<br/>запусков и проверочных данных, исполнитель отладочных запусков и конвертеры<br/>(п. 1.1, подраздел 3.3)"]
    L6["Уровень 6. Клиентское программное обеспечение<br/>веб-браузер рабочего места пользователя<br/>(п. 1.2.5)"]
    EXTC["Смежные компоненты и внешние средства<br/>LPI-VAP-CORE (единая точка входа через СУДИР),<br/>LPI-VAP-MM и исполняющее ядро видеоаналитики<br/>(п. 1.2.4)"]

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

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

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

flowchart LR
    REF["Модели, типы зон<br/>и виды нарушений"] --> EDIT["Создание и настройка<br/>графа сценария"]
    EDIT --> DRAFT["Сохранение<br/>черновика"]
    ASSET["Проверочные видео,<br/>изображения и зоны"] --> DEBUG["Отладочный запуск"]
    DRAFT --> DEBUG
    DEBUG -->|требуется исправление| EDIT
    DEBUG -->|результат принят| PUB["Публикация версии"]
    PUB --> CODE["Исполняемое<br/>представление"]
    CODE --> OUT["Привязка к камерам и исполнение<br/>смежными компонентами Платформы 4.0"]

RS-MER-004. Схема 3.1 — Создание и публикация версии сценария¶

Расположение схемы: 3.1.1. Создание, сохранение и публикация сценария.

sequenceDiagram
    actor U as Пользователь
    participant UI as Веб-интерфейс Платформы 4.0
    participant SB as sbx-sandbox-backend
    participant NR as sbx-node-red-vl
    participant FM as inf-flows-manager
    participant SS as wf-scenario-storage
    participant K as Kafka

    U->>UI: Открыть рабочую версию
    UI->>SB: Создать сессию редактирования
    SB->>SS: Получить граф версии
    SS-->>SB: flow_data и метаданные
    SB->>NR: Запустить экземпляр и загрузить flows.json
    NR-->>UI: Визуальный редактор
    U->>UI: Изменить блоки и связи
    UI->>SB: Сохранить сценарий
    SB->>NR: Получить flows.json сессии
    NR-->>SB: Граф сценария
    SB->>FM: Извлечь параметры блоков
    FM-->>SB: flow_settings
    SB->>SS: Сохранить граф и настройки
    U->>UI: Опубликовать версию
    UI->>SS: Изменить состояние версии
    SS->>K: Опубликованные версии и настройки

RS-MER-005. Схема 3.2 — Выполнение отладочного запуска¶

Расположение схемы: 3.1.2. Отладочный запуск.

sequenceDiagram
    actor U as Пользователь
    participant LS as wf-launch-storage
    participant AS as wf-asset-storage
    participant SS as wf-scenario-storage
    participant SB as sbx-sandbox-backend
    participant C as sbx-celery
    participant S3 as Объектное хранилище
    participant K as Kafka

    U->>LS: Запустить версию на ассете
    LS->>AS: Получить версию и медиафайлы
    AS-->>LS: Метаданные, ссылки и зоны
    LS->>SS: Получить сведения о версии сценария
    SS-->>LS: Метаданные и UUID графа
    LS->>SB: Создать исполнительную сессию
    SB->>SS: Загрузить flows.json
    SB->>C: Передать граф, медиафайлы и зоны
    loop Для каждого файла и кадра
        C->>C: Выполнить цепочку блоков
        C->>S3: Сохранить кадры, сообщения и журналы
        C->>K: Передать состояние запуска
        K-->>LS: Обновить прогресс
    end
    LS->>SB: Закрыть сессию
    LS-->>U: Результаты отладки

RS-MER-006. Схема 3.3 — Логическая структура компонента и его окружение¶

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

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

    subgraph RS["LPI-VAP-RS"]
        NG["sbx-nginx"]
        SB["sbx-sandbox-backend"]
        NR["sbx-node-red-vl"]
        SS["wf-scenario-storage"]
        FM["inf-flows-manager"]
        AS["wf-asset-storage"]
        LS["wf-launch-storage"]
        CEL["sbx-celery"]
    end

    subgraph INFRA["Инфраструктурные сервисы"]
        PG[(PostgreSQL)]
        R[(Redis)]
        K[(Kafka)]
        M[(Объектное хранилище)]
    end

    subgraph ADJ["Смежные компоненты Платформы 4.0"]
        MR["LPI-VAP-MM<br/>реестр моделей"]
        CORE["LPI-VAP-CORE<br/>камеры и зоны"]
        NRI["Исполняющее ядро<br/>видеоаналитики"]
    end

    UI --> NG
    NG --> SB
    NG --> NR
    NG --> SS
    NG --> AS
    NG --> LS
    SB --> NR
    SB --> SS
    SB --> FM
    LS --> AS
    LS --> SS
    LS --> SB
    SB --> CEL
    SS --> PG
    AS --> PG
    LS --> PG
    SB --> R
    CEL --> R
    AS --> M
    CEL --> M
    LS --> M
    SS <--> K
    LS <--> K
    CEL <--> K
    MR --> FM
    MR --> K
    SS --> CORE
    CORE --> K
    K --> NRI

RS-MER-007. Схема 4.1 — Размещение составных частей LPI-VAP-RS в Kubernetes¶

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

flowchart LR
    ARM["Рабочее место<br/>веб-браузер"]
    INGRESS["Ingress и веб-шлюз<br/>HTTPS, WebSocket"]
    subgraph MASTER["Мастер-нода Kubernetes"]
        UI["Редактор и API"]
        STORE["Хранилища сценариев<br/>и запусков"]
        QUEUE["Kafka, Redis<br/>и очередь задач"]
        PVC["Постоянные тома"]
        UI --> STORE
        UI --> QUEUE
        STORE --> PVC
    end
    subgraph COMPUTE["Вычислительная нода Kubernetes (GPU)"]
        RUN["Исполнитель<br/>отладочных запусков"]
        CONV["Конвертеры моделей"]
        WORK["Рабочие каталоги<br/>и временные данные"]
        RUN --> WORK
        CONV --> WORK
    end
    MM["LPI-VAP-MM<br/>модели и ассеты"]
    CORE["LPI-VAP-CORE<br/>камеры и применение сценариев"]

    ARM --> INGRESS --> UI
    UI --> RUN
    UI <--> MM
    UI <--> CORE
    RUN --> STORE

RS-MER-008. Схема 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

RS-MER-009. Схема 5.1 — Вызов редактора сценария пользователем¶

Расположение схемы: 5.1.1. Вызов пользователем.

sequenceDiagram
    actor U as Пользователь
    participant CORE as LPI-VAP-CORE<br/>единая точка входа
    participant SUDIR as СУДИР
    participant UI as Веб-интерфейс Платформы 4.0
    participant GW as Web-шлюз
    participant SB as Бэкенд среды разработки
    participant SS as Хранилище сценариев
    participant NR as Экземпляр редактора Node-RED

    U->>CORE: Открыть Платформу 4.0
    CORE->>SUDIR: Аутентификация пользователя
    SUDIR-->>CORE: Результат и групповые права
    CORE-->>U: Сеанс и разрешённый интерфейс
    U->>UI: Выбрать версию сценария
    UI->>GW: Команда редактирования
    GW->>SB: Создать сессию для версии
    SB->>SS: Получить сохранённый граф
    SS-->>SB: Граф и атрибуты версии
    SB->>NR: Создать экземпляр и загрузить граф
    NR-->>SB: Динамический адрес редактора
    SB-->>UI: Параметры сессии и адрес
    UI-->>U: Рабочая область редактора

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

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

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

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

RS-MER-011. Схема 6.1 — Формирование входных данных отладочного запуска¶

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

flowchart LR
    U["Пользователь"] --> META["Сценарий и версия"]
    U --> GRAPH["Граф и параметры блоков"]
    U --> ASSET["Проверочный ассет<br/>изображения или видео"]
    U --> ZONES["Зоны для файлов"]
    REF["Справочники Платформы 4.0<br/>модели, зоны, события"] --> GRAPH
    META --> VER["Версия сценария"]
    GRAPH --> VER
    ASSET --> AVER["Версия ассета"]
    ZONES --> AVER
    VER --> RUN["Отладочный запуск"]
    AVER --> RUN
    RUN --> EXEC["Исполнительная сессия"]

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

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

flowchart LR
    EDIT["Визуальный редактор"] --> GRAPH["Граф и настройки<br/>версии сценария"]
    GRAPH --> SS[("Хранилище сценариев")]
    SS --> UI["Веб-интерфейс Платформы 4.0"]
    SS -->|"опубликованные версии<br/>и настройки"| CORE["Промышленный контур Платформы 4.0"]

    GRAPH --> RUN["Отладочный запуск"]
    ASSET["Версия проверочного ассета"] --> RUN
    RUN --> PROGRESS["Состояние и прогресс"]
    RUN --> FRAME["Кадры, сообщения,<br/>журналы и события"]
    PROGRESS --> LS[("Хранилище запусков")]
    FRAME --> S3[("Объектное хранилище")]
    LS --> UI
    S3 -->|"подписанные ссылки"| UI

RS-MER-013. Схема А.1 — Пример логической последовательности блоков сценария¶

Расположение схемы: Приложение А (рекомендуемое). Контрольный состав версии сценария.

flowchart LR
    INPUT["Получение кадра"] --> PREP["Подготовка данных"]
    PREP --> MODEL["Выполнение модели"]
    MODEL --> LOGIC["Фильтрация, трекинг<br/>и проверка зон"]
    LOGIC --> EVENT["Формирование события"]
    LOGIC --> VIS["Визуализация результата"]

RS-MER-014. Схема Б.1 — Рекомендуемый жизненный цикл версии сценария¶

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

flowchart LR
    CREATE["Создание сценария<br/>и рабочей версии"] --> SESSION["Сессия визуального<br/>редактирования"]
    SESSION --> EDIT["Изменение блоков,<br/>связей и параметров"]
    EDIT --> SAVE["Сохранение графа<br/>и настроек"]
    SAVE --> DEBUG["Отладочный запуск<br/>на версии ассета"]
    DEBUG -->|"ошибка или замечание"| EDIT
    DEBUG -->|"проверка пройдена"| REVIEW["Решение о публикации"]
    REVIEW --> PUBLISH["Публикация версии"]
    PUBLISH --> USE["Передача версии<br/>смежным компонентам"]
    PUBLISH --> NEW["Создание новой<br/>рабочей версии"]
    NEW --> SESSION

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

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

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

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

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