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

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

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

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

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

Стандарт: ГОСТ 19.505-79

Аннотация¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Ведение каталога сценариев¶

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

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

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

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

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

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

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

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

Действие «Перенести в архив» недоступно, если версии сценария используются на камерах либо у сценария есть неопубликованная версия.

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

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

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

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

3.2.3. Создание и изменение сценария¶

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

1. Нажмите «Добавить сценарий» — откроется форма «Новый сценарий» (рисунок 3.2).

Рисунок 3.2 — Форма «Новый сценарий».

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

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

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

3.2.4. Атрибуты и комментарии¶

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

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

3.3. Работа с версиями сценария¶

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

Страница «Версии сценария» (рисунок 3.3) открывается нажатием на наименование сценария в каталоге и содержит перечень версий, общую информацию, атрибуты и комментарии.

Рисунок 3.3 — Страница «Версии сценария».

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

3.3.1. Создание новой версии¶

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

1. На странице «Версии сценария» нажмите «Добавить новую версию» — откроется форма «Новая версия сценария» (рисунок 3.4). Эта же форма открывается сразу после создания сценария.

Рисунок 3.4 — Форма «Новая версия сценария».

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

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

3.3.2. Черновая версия¶

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

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

Рисунок 3.5 — Перечень версий с черновой версией.

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

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

3.3.3. Просмотр опубликованной версии¶

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

Страница «Просмотр версии сценария» (рисунок 3.6) открывается нажатием на номер опубликованной версии.

Рисунок 3.6 — Страница «Просмотр версии сценария», вкладка «Общая информация».

Вкладка «Общая информация» содержит:

• ссылку «Логика работы версии сценария» — открывает песочницу в режиме просмотра: граф отображается, обработка на проверочных данных доступна, а сохранение изменений заблокировано;
• признак «Используется на N камерах»;
• блок «Категории» и кнопку «Сохранить» — перечень категорий детекции, учитываемых при применении версии на камерах; изменение доступно, когда это предусмотрено полномочиями и назначениями версии;
• таблицу «Модель — Версия» с моделями, используемыми графом;
• блок «Общая информация»: описание, текущая версия, дата публикации, результат (вид несоответствия);
• атрибуты и комментарии.

Вкладка «Результаты тестирования» описана в 3.6.2.

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

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

1. Убедитесь, что граф версии сохранён (п. 3.4.6) и отлажен (п. 3.5).
2. В форме версии нажмите «Сохранить и опубликовать».
3. Убедитесь, что версия отображается в перечне без признака «Черновая версия» и получила дату публикации.

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

• версия доступна для назначения камерам средствами LPI-VAP-CORE;
• версия доступна для проверочного запуска в разделе «Запуски»;
• сведения о версии и используемых моделях передаются исполняющему ядру видеоаналитики.

3.3.5. Версия по умолчанию¶

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

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

3.4. Настройка логики работы версии¶

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

3.4.1. Открытие песочницы¶

Песочница объединяет визуальный редактор и средства отладки версии. Она открывается для конкретной версии сценария: изменения графа относятся только к этой версии.

1. В форме версии нажмите «Настроить логику работы». Откроется страница «Песочница» (рисунок 3.7); компонент создаст сессию редактирования и запустит экземпляр редактора.

Рисунок 3.7 — Страница «Песочница»: область тестирования, журналы и кнопки управления.

1. Дождитесь появления области «Редактирование сценариев» с заголовком «Редактирование сценариев». До загрузки отображается сообщение о загрузке редактора.
2. При необходимости сверните область тестирования кнопкой «Свернуть» либо разверните область редактора кнопкой «Развернуть».

Страница содержит:

• область «Тестирование на видео/изображениях» с панелью журналов (3.5);
• кнопки «Сохранить изменения», «Вернуться к сценарию» и «Обновить зоны и модели из СОВА»;
• область «Редактирование сценариев» со встроенным визуальным редактором.

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

3.4.2. Рабочая область редактора¶

Знание состава редактора нужно для быстрого поиска блоков и контроля структуры графа.

Встроенный редактор (рисунок 3.8) построен на основе Node-RED и содержит:

Рисунок 3.8 — Визуальный редактор: палитра блоков, рабочее поле и боковая панель.

• палитру (слева) — перечень доступных блоков с полем «filter nodes» для поиска по наименованию; блоки сгруппированы в разделы «Базовые блоки», «Продвинутые блоки», а также «common» (блок комментария) и «function» (пользовательский блок «python3 - function»);
• рабочее поле (в центре) — вкладку с наименованием сценария, на которой размещаются блоки и связи; масштаб изменяется кнопками в нижней части поля и колесом мыши;
• боковую панель (справа) — вкладку «info» со сведениями о выбранном блоке и деревом потоков;
• кнопку Deploy — фиксацию текущего состояния графа в сессии редактора.

Граф версии показан на рисунке 3.9: кадр из блока «Видео Фрейм» передаётся блокам «Детектор», «Трекер2», «Добавление детекции в трек», «Создание событий» и «Модуль отправки событий»; блок «Локальный визуализатор» формирует визуализированный кадр для отладки.

Рисунок 3.9 — Граф опубликованной версии сценария.

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

3.4.3. Добавление блоков и связей¶

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

1. Начните граф с блока «Видео Фрейм»: перетащите его из палитры на рабочее поле. Блок является входной точкой сценария и задаёт частоту и размер обрабатываемых кадров.
2. Добавьте блоки обработки: модельные («Детектор», «Классификатор Детекций», «Детектор позы человека», «Инстанс Сегментатор»), логические («Трекер2», «Добавление детекции в зону», «Фильтр детекций по размеру», «python - switch» и другие) и блоки формирования результата («Создание событий», «Модуль отправки событий», «Локальный визуализатор»).
3. Соедините блоки: наведите указатель на выход блока (точка справа), нажмите кнопку мыши и протяните связь до входа следующего блока (точка слева). У блоков с несколькими выходами (например, «python - switch», «Фильтр по зоне - атрибуту») соедините нужный выход.
4. Для удаления блока или связи выделите его и нажмите Delete; для удаления блока также доступна кнопка «Delete» в окне настройки.
5. Для пояснений используйте блок «comment»: он не участвует в обработке.

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

3.4.4. Настройка параметров блока¶

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

1. Дважды нажмите на блок — откроется окно «Edit … node» с вкладкой «Properties» (рисунок 3.10).

Рисунок 3.10 — Окно настройки блока «Детектор».

1. При необходимости измените «Имя узла» — отображаемое наименование блока на рабочем поле.
2. Для модельного блока выберите «Модель» и «Версия» из перечня опубликованных в компоненте управления моделями. После выбора в группе «Категории» отметьте категории детекции, которые блок передаёт дальше, и при необходимости задайте порог уверенности для каждой категории («…_порог»).
3. Заполните базовые настройки блока: минимальные размеры детекции, общий «Порог уверенности», параметры NMS и другие параметры, предусмотренные блоком.
4. В группе «Продвинутые настройки» проверьте имена входных и выходных полей («Входной топик», «Выходной топик» и другие). Изменяйте их только при сознательном построении нескольких параллельных цепочек.
5. Нажмите «Done» для сохранения параметров либо «Cancel» для отмены.

Модели и их версии в перечне соответствуют состоянию, полученному при последнем обновлении зон и моделей (3.4.5). Если требуемая версия модели не отображается, убедитесь, что она опубликована и прошла проверку в компоненте управления моделями, затем обновите зоны и модели. Значения параметров конкретных блоков приведены в описании поставляемых логических блоков.

3.4.5. Обновление зон и моделей¶

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

1. Нажмите «Обновить зоны и модели из СОВА».
2. Дождитесь сообщения «Зоны и модели успешно обновлены».
3. Повторно откройте окно настройки модельного блока и проверьте перечень версий.

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

3.4.6. Сохранение изменений графа¶

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

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

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

3.5. Отладка версии на проверочных данных¶

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

3.5.1. Загрузка проверочного файла¶

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

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

Для загрузки из ассета:

1. Нажмите «Загрузите файл из ассета» — откроется окно «Загрузка видео из ассета» (рисунок 3.11).

Рисунок 3.11 — Выбор файла из версии ассета.

1. Выберите «Ассет» и «Версия»; отобразится перечень файлов версии. Если у ассета нет версий с файлами, выводится подсказка «Нет версий с медиафайлами».
2. Отметьте файл и нажмите «Выбрать».

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

3.5.2. Загрузка зон¶

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

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

Если для файла ассета зоны не размечены, выводится сообщение «Зоны не найдены»; разметьте зоны в версии ассета средствами компонента управления моделями либо подготовьте файл зон. При файле иного формата выводится «Файл должен быть в формате JSON». Тип зоны должен соответствовать типу, ожидаемому блоками сценария.

3.5.3. Запуск обработки и просмотр кадров¶

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

1. Убедитесь, что граф зафиксирован в редакторе кнопкой «Deploy»: обработка выполняется по текущему состоянию сессии.
2. Нажмите «Начать обработку». Выводится сообщение «Обработка началась», кнопка заменяется на «Остановить обработку», под ползунком отображаются счётчики «Обработанных фреймов N из M» и «Шаг обработки: N из M» (рисунок 3.12).

Рисунок 3.12 — Результат обработки видеозаписи: визуализированный кадр и общий журнал.

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

Число шагов обработки определяется частотой кадров, заданной в блоке «Видео Фрейм»: при значении входного fps ниже частоты исходного видео обрабатывается часть кадров. Для изображения выполняется один шаг.

3.5.4. Анализ журналов и событий¶

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

Панель справа от области просмотра содержит вкладки:

• «Лог» — общий журнал сессии обработки: загрузка файла, инициализация моделей, ход обработки и ошибки;
• «Лог фрейма» — журнал выбранного кадра: перечень блоков в порядке выполнения с временем работы каждого, например «Node "Детектор" :Detector executed in 55.58ms»;
• «Лог сообщений» — содержимое контейнера сообщения после выполнения графа на выбранном кадре в виде дерева полей: изображение, метка времени, индексы кадра и шага, параметры камеры, детекции, треки, визуализированный кадр, события;
• «События» — таблица событий, сформированных на кадрах: «ID трека», «ID категории», «Индекс кадра», «Шаг кадра», «Время» (рисунок 3.13).

Рисунок 3.13 — Вкладка «События» после обработки видеозаписи.

Рекомендуемый порядок разбора:

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

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

3.5.5. Завершение отладки¶

Результаты отладки в песочнице относятся к сессии редактора и после ухода со страницы недоступны. Для воспроизводимой фиксации результата проверки используйте проверочный запуск (3.6).

Перед уходом со страницы:

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

3.6. Проверочные запуски версии¶

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

3.6.1. Запуск тестирования¶

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

1. Откройте опубликованную версию и перейдите на вкладку «Результаты тестирования» (рисунок 3.14).

Рисунок 3.14 — Вкладка «Результаты тестирования» версии сценария.

1. Нажмите «Запустить тестирование» — откроется форма «Запуск» раздела «Настройки → Запуски» с заполненными полями «Тип запуска» — «Сценарий», «Название» и «Версия» (рисунок 3.15). Форму также можно открыть кнопкой «Добавить запуск» в разделе «Запуски», выбрав тип «Сценарий» вручную.

Рисунок 3.15 — Форма «Запуск» для версии сценария.

1. В поле «Ассет» выберите набор проверочных данных, в поле «Версия» — его опубликованную версию. В списках отображаются только опубликованные версии сценария и ассета.
2. Нажмите «Запустить».

Контроль выполнения, вкладки «Файлы», «Лог», «Лог фрейма», «Лог сообщений», «События», а также фиксация результата в блоке «Результат» («Тест пройден», «Тест пройден с ошибками», «Тест не пройден») и кнопкой «Сохранить результат» выполняются так же, как для проверки модели, и описаны в подразделе 3.5 руководства пользователя компонента управления моделями.

3.6.2. Результаты тестирования версии¶

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

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

3.7. Применение версии сценария¶

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

3.7.1. Контроль использования на камерах¶

В перечне версий столбец «Используется на камерах» показывает число камер, которым назначена версия; на странице просмотра версии выводится признак «Используется на N камерах». Нажатие на значение открывает окно с перечнем камер.

Версия, назначенная камерам, защищена от переноса в архив. Назначение версии камере и его снятие выполняются в карточке камеры средствами Центрального модуля (см. подраздел 3.3.3 руководства пользователя LPI-VAP-CORE).

3.7.2. Обновление версии сценария на камерах¶

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

1. На странице «Версии сценария» нажмите «Обновить сценарии до версии» — откроется окно «Обновление версии сценария на камерах» (рисунок 3.16).

Рисунок 3.16 — Окно «Обновление версии сценария на камерах».

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

При сообщении «При обновлении сценариев произошла ошибка» проверьте доступность камер и повторите операцию только для необновлённых камер.

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

Замена версии модели выполняется из карточки модели в компоненте управления моделями командой «Обновить сценарии до версии» (подраздел 3.6.2 руководства пользователя LPI-VAP-MM). Для каждого выбранного сценария компонент создаёт новую опубликованную версию с заменённой ссылкой на модель; остальные параметры графа не изменяются.

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

3.8. Архив сценариев и версий¶

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

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

3.8.1. Архивирование сценария или версии¶

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

При наличии черновой версии перенос отклоняется с сообщением «Нельзя перенести в архив так как есть неопубликованная версия»; интерфейс может показать исходный текст ошибки сервера с указанием идентификатора сценария. Черновая версия удаляется без переноса в архив.

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

Кнопки «Архив сценариев» и «Архив версий» раздела «Сценарии» открывают соответствующие архивы (рисунок 3.17).

Рисунок 3.17 — Страница «Архив сценариев».

Архив содержит поле «Время хранения» в днях с кнопкой «Применить», кнопку «Вернуть в хранилище» и перечень со столбцами «Название», «Описание», «Дата отправки в архив», «Переместил», «До окончания хранения». В строке доступно действие «Удалить сценарий» (для версии — удаление версии).

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

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

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

Завершение работы нужно для сохранения введённых данных и защиты учётной записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения¶

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

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

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

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

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

Б.1. Разработка нового сценария¶

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

1. Убедитесь, что требуемые модели опубликованы и проверены в компоненте управления моделями, а проверочные данные подготовлены в версии ассета.
2. Создайте сценарий и заполните каталог, описание и атрибуты (3.2.3).
3. В форме первой версии нажмите «Настроить логику работы» (3.4.1).
4. Нажмите «Обновить зоны и модели из СОВА», соберите граф из блоков и задайте параметры (3.4.3, 3.4.4).
5. Зафиксируйте граф кнопкой «Deploy», загрузите проверочный файл и зоны, выполните обработку и разберите журналы и события (3.5).
6. Нажмите «Сохранить изменения», вернитесь к сценарию и выберите «Сохранить и опубликовать» (3.3.4).
7. Выполните проверочный запуск на версии ассета и зафиксируйте результат (3.6).
8. Назначьте версию камерам средствами LPI-VAP-CORE и проверьте появление событий в журнале.

Б.2. Изменение логики применяемого сценария¶

Цель — изменить параметры сценария, не нарушая работу камер до проверки новой версии.

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

Б.3. Перевод сценариев на новую версию модели¶

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

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

Б.4. Разбор сценария, не формирующего события¶

Цель — найти блок или параметр, из-за которого событие не формируется.

1. Откройте логику версии в режиме просмотра либо создайте новую рабочую версию для исправления.
2. Загрузите видеозапись или кадр, на котором событие ожидается, и зоны того типа, который используют блоки сценария (3.5.1, 3.5.2).
3. Выполните обработку и на кадре с ожидаемым событием проверьте «Лог фрейма»: все ли блоки выполнены и нет ли ошибок (3.5.4).
4. В «Лог сообщений» проверьте поля детекций, треков и зон: пустое поле указывает на блок, который не передал данные дальше.
5. Проверьте пороги уверенности, отмеченные категории и имена полей в параметрах блоков; исправьте, зафиксируйте граф и повторите обработку.
6. Опубликуйте исправленную версию и обновите её на камерах.

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

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

1. Проверьте использование версий на камерах (3.7.1).
2. Снимите назначения сценария в карточках камер средствами LPI-VAP-CORE либо переведите камеры на другой сценарий.
3. Опубликуйте либо удалите черновую версию, если она есть.
4. Перенесите сценарий в архив (3.8.1).
5. Не удаляйте архивную запись до истечения срока хранения и подтверждения отсутствия зависимостей.

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

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

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

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

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

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

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

Приложение Д (справочное). Стандартные логические блоки¶

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

Таблица Д.1 — Назначение стандартных логических блоков.

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

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

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

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

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

flowchart LR
    CREATE["Создать сценарий<br/>и рабочую версию"] --> LOGIC["Настроить логику работы:<br/>блоки, параметры, связи"]
    LOGIC --> DEPLOY["Зафиксировать граф (Deploy)<br/>и сохранить изменения"]
    DEPLOY --> DEBUG["Отладить на изображении<br/>или видеозаписи"]
    DEBUG --> REVIEW{"Результат<br/>приемлем?"}
    REVIEW -->|нет| LOGIC
    REVIEW -->|да| PUBLISH["Сохранить и опубликовать<br/>версию"]
    PUBLISH --> TEST["Выполнить проверочный запуск<br/>на версии ассета"]
    TEST --> APPLY["Назначить версию камерам<br/>средствами LPI-VAP-CORE"]
    APPLY --> NEXT["Изменения — в новой версии"]
    NEXT --> LOGIC

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

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

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

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

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