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

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

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

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

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

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

Аннотация¶

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

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

Исполняемые составные части поставляются контейнерными образами и размещаются в кластере Kubernetes на серверных ЭВМ архитектуры x86 под управлением «Московской серверной операционной системы». Узлы кластера разделены по назначению: мастер-нода выполняет прикладные сервисы, веб-интерфейс и общесистемные хранилища (PostgreSQL, ClickHouse, Apache Kafka, S3-совместимое объектное хранилище, кэш); вычислительные ноды выполняют приём и декодирование видеопотоков, исполнение моделей видеоаналитики и подготовку видеофрагментов на графических процессорах класса NVIDIA T4. Пользователь работает с компонентом через веб-браузер на персональном компьютере или тонком клиенте; установка исполняемых частей компонента на рабочее место не требуется.

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

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

Термины, определения и сокращения¶

В настоящем документе применены следующие термины с соответствующими определениями.

В настоящем документе применены следующие сокращения и обозначения.

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

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

Компонент поставляется как простая (неисключительная) лицензия на программу для ЭВМ «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0») в составе «Центральный модуль управления данными и распределёнными вычислениями, арт. LPI-VAP-CORE» и является управляющим и исполняющим контуром Платформы 4.0.

В соответствии со спецификацией на поставку компонент обеспечивает: ведение иерархической структуры (округ, адрес, камера) с произвольной вложенностью; создание и редактирование учётных записей, присвоение ролей и назначение полномочий с разграничением доступа к данным и управляющим действиям на основе ролевой модели; создание, редактирование и удаление камер с указанием типа, протокола передачи данных и параметров подключения, их привязку к объектам и управление статусом активности; создание типов зон, зон на изображении камеры и пиксельных полигонов; привязку и отвязку исполняемых версий сценариев к камерам из версионного хранилища; динамическую балансировку нагрузки и распределение источников данных между вычислительными ресурсами; поддержку моделей компьютерного зрения для задач классификации, детекции и сегментации и логическую обработку их результатов; автоматическую фиксацию событий и нарушений в зонах при срабатывании заданных условий, их обработку и долговременное хранение вместе со связанными медиаданными в форматах JPG, PNG и MP4; представление камер, событий и нарушений в интерфейсе, принятие решений и комментирование; сбор, хранение и визуализацию логов действий пользователей; настройку правил уведомлений и их отправку по электронной почте; вычисление агрегированных статистических показателей, формирование отчётов и их выгрузку в форматах PDF и XLSX; создание и модификацию параметров подключения внешних источников медиаданных и синхронизацию с ними перечней камер; приём видеопотоков от камер и отдельных кадров от сервисов снятия скриншотов, просмотр трансляций и архивных записей встроенным плеером; обмен данными с внешними интеграционными интерфейсами — синхронизацию идентификаторов камер и передачу событий видеоаналитики с указанием идентификатора задачи.

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

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

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

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

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

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

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

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

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

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

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

Приведённые версии подтверждены по контрольной сборке компонента и при формировании целевой поставки подлежат сверке с её ведомостью контейнерных образов. PostgreSQL, ClickHouse и MinIO содержат постоянные данные и включаются в резервное копирование. Аутентификация пользователей выполняется во внешней системе единого входа по протоколу OIDC/OAuth 2.0; ролевая модель, полномочия и область видимости объектов ведутся собственными составными частями компонента (п. 1.2.4).

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

Основные библиотеки и фреймворки приведены в таблице.

Указанные версии являются минимально допустимыми: разные составные части могут использовать более новые совместимые версии. Для эксплуатации применяются готовые контейнерные образы; установка Python-, Node.js- и вычислительных библиотек непосредственно в целевую операционную систему не требуется. Точный состав каждого образа фиксируется в формуляре поставки.

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

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

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

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

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

Сторонние общесистемные средства (СУБД, брокер сообщений, объектное хранилище, медиасервер, средства мониторинга) поставляются готовыми образами; языки их реализации не являются языками прикладной логики LPI-VAP-CORE и в таблице не приводятся.

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

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

Компонент не выполняет загрузку, конвертацию и версионирование моделей, не предоставляет среду разработки и отладки сценариев и не исполняет мультимодальные языковые модели. Эти функции реализованы компонентами LPI-VAP-MM, LPI-VAP-RS и LPI-VAP-MLLM. Компонент применяет их результаты: опубликованные версии моделей и сценариев — при обработке видеопотоков, а результаты мультимодальной обработки — при формировании и проверке событий.

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

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

Схема 2.1 — Функциональный цикл компонента LPI-VAP-CORE.

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

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

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

Таблица 2.3.1 — Показатели назначения компонента LPI-VAP-CORE.

Дополнительно к таблице 2.3.1 целевыми требованиями установлены показатели масштаба: количество подключаемых камер не ограничивается лицензионной политикой, а при опросе одного кадра раз в две минуты обрабатываются кадры не менее чем от 6000 камер на инфраструктуре из мастер-ноды и четырёх вычислительных нод. Расчёт числа вычислительных нод, порядок масштабирования и характеристики оборудования приведены в разделе 4.

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

1. конфигурация технических средств соответствует разделу 4: число и характеристики мастер-ноды и вычислительных нод, количество и модель графических ускорителей, параметры сети и хранилищ;
2. системное время на всех узлах синхронизировано с единым источником, что обеспечивает единую хронологию кадров, событий и записей аудита;
3. число камер, интервалы опроса и назначенные версии сценариев не превышают значений, на которые рассчитана конфигурация (подразделы 4.2 и 4.3);
4. время обработки события отсчитывается от метки времени кадра, присвоенной при приёме медиаданных, до появления события в динамическом потоке и журнале интерфейса;
5. задержка отклика интерфейса отсчитывается от действия пользователя до полной отрисовки экранной формы при штатном объёме отображаемых данных;
6. время формирования отчёта отсчитывается от подтверждения параметров выгрузки до получения готового файла и зависит от объёма выборки, периода и наличия изображений;
7. скорость обработки кадров относится к устойчивому режиму работы вычислительной ноды и учитывает только успешно обработанные кадры;
8. время обработки API-запроса относится к штатной нагрузке и не включает первичную синхронизацию перечня камер с внешним источником;
9. время отправки события во внешнюю систему отсчитывается от записи события в журнал до подтверждения приёма внешним интерфейсом и обеспечивается при штатном времени отклика этой системы.

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

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

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

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

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

Схема 3.1 — Общий алгоритм работы компонента LPI-VAP-CORE.

3.1.1. Аутентификация, авторизация и разграничение доступа¶

1. Пользователь обращается к веб-интерфейсу; шлюз выдаёт клиентское приложение и маршрутизирует последующие запросы к сервисам компонента.
2. Аутентификация выполняется во внешней системе единого входа по протоколу OIDC/OAuth 2.0 в режиме авторизационного кода: пользователь перенаправляется на адрес авторизации внешней системы с идентификатором зарегистрированного приложения, запрошенными разрешениями, адресом возврата и случайным идентификатором запроса, который защищает от перехвата и возвращается в ответе. При наличии действующей сессии внешняя система возвращает авторизационный код, иначе предварительно запрашивает учётные данные пользователя.
3. Полученный авторизационный код обменивается на маркер доступа, маркер обновления и маркер идентификации. Сведения о пользователе и его групповых правах запрашиваются средствами аутентификации и авторизации внешней системы; доступ предоставляется при наличии соответствующего группового права. Сессионные данные размещаются в кэше, срок действия маркера доступа контролируется, а его продление выполняется по маркеру обновления без повторного входа пользователя. Маркер обновления предоставляется, если это предусмотрено параметрами зарегистрированного приложения.
4. Каждый последующий запрос сопровождается маркером. Шлюз проверяет его действительность, определяет пользователя и передаёт контекст сервисам.
5. Сервис разграничения доступа хранит назначенные роли, полномочия и область видимости — перечень объектов и камер, доступных пользователю. Проверка выполняется как для операций изменения, так и для выборок: пользователь получает только те объекты, камеры и события, которые входят в его область.
6. Выполненные действия публикуются в топик аудита и сохраняются сервисом аудита с указанием пользователя, времени, вида операции и объекта изменения.
7. Ветвления. Неуспешная аутентификация во внешней системе единого входа — отказ во входе и запись в журнал. Истёкший маркер доступа — продление по маркеру обновления либо повторный вход. Отсутствие требуемого группового права — отказ в доступе к компоненту. При недоступности внешней системы единого входа вход новых пользователей невозможен, действующие сессии продолжают работу до истечения срока действия маркера. При недоступности сервиса разграничения доступа операция не выполняется: отсутствие подтверждённого полномочия трактуется как отказ.

Последовательность входа пользователя приведена на схеме 3.2.

Схема 3.2 — Последовательность входа пользователя.

3.1.2. Управление иерархией объектов, камерами и зонами¶

1. Пользователь создаёт и изменяет элементы иерархии (округ, адрес, объект) с произвольной глубиной вложенности. Структура хранится в транзакционном хранилище и используется для навигации, разграничения доступа, фильтрации событий и построения отчётов.
2. При регистрации камеры указываются тип подключения и протокол передачи данных, параметры подключения, наименование, расположение, привязка к объекту, режим включения (постоянно или по расписанию) и интервал опроса кадров, а также набор категорий детекции.
3. Изменения состава и параметров камер публикуются в топики добавления, обновления и удаления камеры. Их получают распределение нагрузки, приём медиаданных, обработка кадров, хранилище событий и статистика, что обеспечивает согласованное представление камеры во всех контурах.
4. Типы зон ведутся как справочник; изменения публикуются отдельными сообщениями и доводятся до контуров, использующих зоны. Категории детекции объединяются в наборы (пресеты), назначаемые камерам.
5. Зоны камеры создаются на её изображении в виде связанных или независимых пиксельных полигонов. Разметка сохраняется вместе с эталонным кадром и параметрами масштабирования; изменение зон публикуется сообщением об обновлении зон камеры и применяется исполняющим контуром без перезапуска остальных камер.
6. Статусы поддерживаются автоматически: камера периодически подтверждает доступность сигналом heartbeat, исполняющий контур — состояние детекторов. Отсутствие подтверждения дольше заданного времени переводит камеру в статус «недоступна» и публикует соответствующее сообщение. Интерфейс получает обновления статусов и превью через WebSocket без перезагрузки страницы.

7. Ветвления. Изменение параметров подключения приводит к переинициализации приёма медиаданных для этой камеры. Удаление камеры не удаляет ранее зарегистрированные события: они сохраняются со ссылкой на исторические сведения о камере. Конфликт наименований при синхронизации с внешним источником разрешается по правилам, описанным в п. 3.1.3.

8. Камере назначается тип ракурса из справочника. Тип ракурса закрепляет за изображением камеры перечень промптов — проверок, выполняемых мультимодальной языковой моделью, — и пресетов. Изменение состава промптов у типа ракурса применяется ко всем камерам, которым он назначен.

3.1.3. Подключение и синхронизация источников медиаданных¶

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

3.1.4. Распределение нагрузки и выполнение видеоаналитики¶

1. Для камеры включается видеоаналитика и назначается опубликованная версия сценария из версионного хранилища. Назначение сохраняется в карточке камеры и публикуется сообщением о составе сценариев камеры; отвязка выполняется тем же способом.
2. Распределение нагрузки ведёт перечень вычислительных нод, их доступность, загрузку и весовые коэффициенты. Камеры распределяются между нодами; при добавлении камеры, изменении состава нод или превышении заданного порога рассогласования выполняется перебалансировка с ограничением частоты перераспределения.
3. Вычислительная нода получает назначенные камеры, загружает исполняемый код версии сценария и исполняемые артефакты моделей из хранилища моделей, инициализирует конвейер обработки на графическом ускорителе и подтверждает готовность.
4. Кадры поступают из потока, декодируемого медиасервером, либо из покадрового контура. Для каждого кадра выполняются модели классификации, детекции и сегментации, после чего результаты обрабатываются логическими блоками сценария с учётом зон камеры и заданных условий.
5. Результаты публикуются в шину: детекции — отдельным потоком, нарушения — потоком событий. Дополнительно публикуются подтверждения работоспособности обработки, состояние детекторов камеры и метрики производительности.
6. Перед публикацией нарушения применяется фильтр одиночных срабатываний: событие формируется при накоплении заданного числа подтверждений в пределах интервала. Параметры фильтра задаются настройками поставки.
7. Ветвления. Прекращение подтверждений от ноды переводит её в недоступное состояние, а закреплённые камеры перераспределяются между оставшимися. Отсутствие свободного ресурса откладывает назначение камеры до освобождения мощностей. Ошибка загрузки модели или версии сценария фиксируется, камера помечается как необработанная, и обработка остальных камер продолжается. Недоступность источника обрабатывается по п. 3.1.3.

3.1.5. Формирование, хранение и обработка событий¶

Жизненный цикл события приведён на схеме 3.3.

Схема 3.3 — Жизненный цикл события и нарушения.

1. Исполняющий контур публикует результат сценария с указанием камеры, зоны, категории, времени, кадра и координат обнаруженных областей.
2. Фильтр событий отсеивает результаты, не подлежащие регистрации, и передаёт остальные на применение правил. Правила определяют вид нарушения, учитывают категории, зоны и заданные исключения и формируют команду регистрации события.
3. Хранилище событий создаёт запись с идентификатором, привязкой к камере, зоне, объекту и категории, сохраняет размеченное изображение и превью в объектном хранилище, а карточку события — в транзакционном хранилище. Для выборок, статистики и отчётов записи дополнительно ведутся в аналитическом хранилище.
4. В течение настраиваемого окна к событию добавляются дополнительные материалы: кадры, полученные позднее, и видеофрагмент. Видеофрагмент формируется по запросу к сервису подготовки видео, который возвращает ссылку на файл; при недоступности видеофрагмента событие остаётся действительным с изображениями.
5. Похожие события одной камеры и категории могут объединяться в группу в пределах заданного временного окна, что уменьшает дублирование записей в журнале.
6. При включённой дополнительной проверке событие передаётся компоненту обработки мультимодальных данных; полученный результат подтверждает, отклоняет или дополняет событие.
7. Зарегистрированное событие немедленно публикуется в динамический поток интерфейса через WebSocket и становится доступным в журнале с сортировкой по дате и времени, камере, зоне, сценарию и решению и с фильтрацией по дате и времени, расположению, сценарию, категории и решению.
8. Оператор открывает карточку события, просматривает изображение и видеофрагмент, подтверждает или отклоняет событие и добавляет комментарий. Решение и комментарии сохраняются вместе с историей изменений и автором.
9. Очистка хранилища выполняется по заданным правилам: по сроку хранения и по предельному объёму, начиная с отклонённых и наиболее старых событий.
10. Ветвления. Недоступность объектного хранилища не приводит к потере события: сообщение остаётся в очереди и повторяется, а карточка сохраняется без медиаматериалов до успешной записи. Недоступность аналитического хранилища ограничивает статистику и отчёты, не влияя на регистрацию событий. Переполнение хранилища обрабатывается политикой очистки.

3.1.6. Уведомления, статистика, отчёты и интеграционный обмен¶

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

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

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

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

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

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

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

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

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

Компонент эксплуатируется на серверных технических средствах заказчика в составе Платформы 4.0. Целевое развёртывание выполняется в кластере Kubernetes: составные части поставляются контейнерными образами и размещаются на узлах кластера в соответствии с их назначением. Установка исполняемых частей компонента на рабочее место пользователя не требуется: работа выполняется через веб-браузер.

Узлы кластера разделены на два типа по назначению:

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

Требования к техническим средствам заданы двумя уровнями. Количественные требования к ресурсам каждого типа узла установлены подразделом 4.2 по требованиям к инфраструктуре заказчика для позиции поставки LPI-VAP-CORE. Качественные требования, минимально допустимые версии программной среды и удельные величины для расчёта ёмкости приведены в подразделе 4.3 раздельно по типам узлов в форме «не ниже».

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

4.1.1. Назначение узлов кластера¶

Таблица 4.1.1 — Назначение узлов кластера.

Число вычислительных нод определяется требуемым числом камер и профилем их опроса (подраздел 4.2.3). Совмещение назначений мастер-ноды и вычислительной ноды на одном узле допускается при обеспечении суммарных ресурсов подраздела 4.2 и выполнении показателей назначения подраздела 2.3.

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

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

Схема 4.1 — Развёртывание компонента по типам узлов кластера.

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

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

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

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

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

4.2. Минимальная конфигурация серверного оборудования¶

Минимальные ресурсы приведены по типам узлов кластера. Итоговые значения по компоненту (подраздел 4.2.3) соответствуют требованиям к инфраструктуре заказчика для позиции поставки LPI-VAP-CORE.

4.2.1. Мастер-нода¶

Таблица 4.2.1 — Минимальные ресурсы мастер-ноды.

Ресурсы мастер-ноды определяются числом камер и объектов, темпом поступления событий, глубиной хранения медиаданных и профилем отчётности. Ёмкость HDD рассчитывается по удельным величинам п. 4.3.2 и установленным срокам хранения.

4.2.2. Вычислительная нода¶

Таблица 4.2.2 — Минимальные ресурсы вычислительной ноды.

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

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

Одна вычислительная нода обеспечивает обработку не менее 45 000 кадров в час (подраздел 2.3), что соответствует примерно 1500 камерам при опросе одного кадра раз в две минуты.

4.2.3. Суммарная конфигурация и масштабирование¶

Таблица 4.2.4 — Суммарная минимальная конфигурация серверного оборудования LPI-VAP-CORE.

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

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

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

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

Таблица 4.3.1 — Требования к узлам целевой конфигурации, не нормированные подразделом 4.2.

Число вычислительных нод определяется профилем камер (п. 4.2.3).

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

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

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

Ёмкость объектного хранилища медиаданных рассчитывается как произведение ожидаемого числа событий в сутки, суммарного размера сохраняемых материалов одного события (изображение — не менее 100 КБ, при подготовке видеофрагмента дополнительно его размер) и установленного срока хранения, с запасом не менее 20 %. Пропускная способность каналов к рабочим местам рассчитывается по числу одновременно просматриваемых трансляций и их битрейту.

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

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

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

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

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

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

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

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

1. Пользователь открывает в браузере адрес веб-интерфейса Платформы 4.0. Адрес является параметром целевой поставки.
2. Загружается клиентское приложение, после чего пользователь перенаправляется на страницу входа внешней системы единого входа, где вводит учётные данные. При наличии действующей сессии возврат в интерфейс выполняется без повторного ввода.
3. При успешной аутентификации и наличии группового права доступа открывается главная страница. Состав доступных разделов и операций определяется ролью и полномочиями учётной записи, а состав отображаемых объектов и камер — назначенной областью видимости.
4. Из главной страницы выполняется переход к разделам: иерархия объектов и перечень камер в табличном и плиточном представлении, карточка камеры с трансляцией, зонами и назначенными сценариями, динамический поток событий, журнал событий и нарушений, карточка события, информационная панель, отчёты, справочники типов зон и категорий, пользователи и роли, журнал аудита, настройки источников медиаданных и правил уведомлений.
5. Признаками успешной загрузки являются: отображение дерева объектов и плиток камер с актуальными статусами и превью, поступление новых событий в динамический поток, наличие записей в журнале за выбранный период и воспроизведение трансляции в карточке камеры.
6. Сессия завершается выходом пользователя либо по истечении срока действия маркера доступа; после этого требуется повторный вход.

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

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

Условия запуска:

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Браузер получает клиентское приложение и параметры оформления интерфейса. Эта часть загружается до аутентификации и не содержит прикладных данных.
2. Пользователь аутентифицируется во внешней системе единого входа; полученный авторизационный код обменивается на маркер доступа, маркер обновления и маркер идентификации. Маркер доступа сохраняется в браузере и передаётся с каждым последующим запросом, продление выполняется по маркеру обновления.
3. Загружается профиль пользователя: роли, полномочия, доступная область объектов и камер, настройки интерфейса.
4. Загружаются справочники (типы зон, категории детекции, виды нарушений), иерархия объектов и перечень камер с текущими статусами и превью в объёме области видимости пользователя.
5. Устанавливается соединение WebSocket; интерфейс подписывается на динамический поток событий, изменения статусов камер и детекторов и уведомления о ходе выполнения длительных операций.
6. При открытии карточки камеры запрашивается трансляция (HLS или WebRTC), при открытии журнала — выборка событий с учётом фильтров и области видимости, при открытии информационной панели — агрегированные показатели.
7. По истечении срока действия маркера выполняется его обновление; при неуспехе сессия завершается и запрашивается повторный вход.
8. При недоступности отдельного сервиса интерфейс отображает доступные данные и признак недоступности соответствующего раздела: отсутствие трансляции не препятствует работе с журналом событий, недоступность статистики не влияет на регистрацию событий. Соединение WebSocket восстанавливается автоматически, а после восстановления интерфейс получает актуальное состояние.

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

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

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

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

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

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

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

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

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

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

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

Маршруты поступления входных данных приведены на схеме 6.1.

Схема 6.1 — Маршруты поступления входных данных.

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

До начала обработки должны быть выполнены следующие условия.

1. Компонент зарегистрирован как приложение во внешней системе единого входа: согласованы идентификатор приложения, разрешённые адреса возврата, запрашиваемые разрешения и состав передаваемых сведений о пользователе. Пользователям предоставлены групповые права доступа к компоненту, назначены роли, полномочия и области видимости объектов и камер.
2. Сформирована иерархия объектов наблюдения, соответствующая предметной структуре заказчика.
3. Обеспечена сетевая доступность источников медиаданных и внешних систем с серверов Платформы 4.0, согласованы реквизиты доступа и правила фильтрации трафика.
4. Заполнены параметры подключения камер: тип подключения, адрес источника, реквизиты доступа, интервал опроса кадров, режим работы и расписание, привязка к объекту, расположение.
5. Выполнена синхронизация перечня камер с внешней системой видеонаблюдения; установлено соответствие внутренних и внешних идентификаторов камер.
6. Актуализированы справочники: типы зон, категории детекции и виды нарушений; камерам назначены необходимые наборы категорий.
7. Выполнена разметка зон на изображении камеры: созданы пиксельные полигоны, указаны типы зон и параметры, необходимые логике сценария.
8. В компонентах LPI-VAP-MM и LPI-VAP-RS опубликованы версии моделей и сценариев, применяемые для контролируемых нарушений; опубликованная версия сценария назначена камере.
9. Развёрнуты и готовы вычислительные ресурсы: доступны вычислительные ноды с графическими ускорителями, загружены исполняемые артефакты моделей.
10. Проверены форматы и параметры медиаданных: кодек, разрешение и частота кадров источника поддерживаются средствами приёма и декодирования; для покадрового режима подтверждены формат и размер получаемого изображения.
11. Настроены правила уведомлений и параметры внешних служб доставки, а также параметры интеграционного обмена, включая идентификатор задачи и условия передачи событий.
12. Синхронизировано системное время на серверах компонента и, по возможности, на источниках медиаданных.

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

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

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

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

6.4.1. Пользователи, роли, полномочия и иерархия объектов¶

6.4.2. Камеры, источники подключения и зоны¶

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

6.4.3. Видеопотоки, кадры и архивные записи¶

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

6.4.4. Сценарии, модели и команды вычислительного контура¶

6.4.5. События, решения и правила уведомлений¶

6.4.6. Интеграционные, справочные и управляющие данные¶

6.4.7. Сведения о пользователе, получаемые от внешней системы единого входа¶

Состав сведений определяется разрешениями (scope), согласованными при регистрации приложения во внешней системе единого входа.

Таблица 6.4.1 — Сведения о пользователе по запрашиваемым разрешениям.

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

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

Таблица 6.5.1 — Способы кодирования входных данных.

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

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

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

Таблица 7.1.1 — Группы выходных данных компонента.

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

Маршруты предоставления выходных данных приведены на схеме 7.1.

Схема 7.1 — Маршруты предоставления выходных данных.

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

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

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

7.3.1. Пользователи, права доступа и аудит¶

7.3.2. Иерархия, камеры и состояния вычислительного контура¶

7.3.3. События, нарушения и связанные медиаданные¶

7.3.4. Уведомления, статистика и отчёты¶

7.3.5. Интеграционные сообщения, результаты операций и ошибки¶

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

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

Таблица 7.4.1 — Способы кодирования выходных данных.

Приложения¶

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

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

Таблица А.1 — Контрольный состав конфигурации камеры.

Рекомендуемая последовательность ввода камеры в эксплуатацию приведена на схеме А.1.

Схема А.1 — Рекомендуемая последовательность ввода камеры в эксплуатацию.

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

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

Схема Б.1 — Жизненный цикл камеры.

Жизненный цикл события приведён на схеме Б.2. Решение оператора не изменяет исходные результаты обработки: они сохраняются вместе с историей изменений статуса.

Схема Б.2 — Жизненный цикл события.

Приложение В (справочное). Состояния и основные информационные потоки¶

В.1. Состояния объектов контроля¶

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

В.2. Карта основных информационных потоков¶

Таблица В.2 — Карта основных входных и выходных сообщений.

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

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

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

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

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

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

Рабочая редакция 0.1 отражает первоначальное заполнение документа в формате docs-as-code и не является зарегистрированным изменением утверждённого оригинала. При выпуске утверждаемой редакции необходимо:

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

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