Сценарии: подробная методология разработки

Связанный экран.

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

flowchart LR
    C[Камера или внешний источник] --> V[Получение кадров]
    V --> I[Выполнение сценария на вычислительном узле]
    R[Модели и опубликованные версии сценариев] --> I
    Z[Зоны и настройки камеры] --> I
    I --> E[Обработка событий]
    E --> J[Журнал и решение оператора]
    E --> N[Уведомления и интеграции]
    I --> M[Медиаданные]
    A[Проверочный ассет] --> S[Песочница и тестовый запуск]
    R --> S
    S --> R

Схема показывает функциональные связи. Контейнерные сервисы обмениваются сообщениями; оперативные данные, аналитика и медиа хранятся раздельно. В типовой архитектуре используются Docker/Swarm, Kafka, PostgreSQL, ClickHouse, Redis и S3-совместимое хранилище. Конкретную топологию и набор компонентов уточните у системного администратора вашей установки.

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

Связанный экран.

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

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

Шаг 2. Отделите наблюдаемое от предполагаемого. Модель видит голову без каски или голову, состояние которой неизвестно. Класс «неизвестно» не равен классу «нет каски». Аналогично отсутствие найденного человека не доказывает отсутствие человека при потере видео.

Шаг 3. Зафиксируйте договорённости. Какие камеры и зоны участвуют? Что считать началом и окончанием эпизода? Как обрабатывать перекрытие, пропуск кадра, смену смены, обрыв связи? Что отправлять оператору? Какие параметры могут различаться по камерам?

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

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

Шаг 6. Соберите минимальную цепочку. Кадр → модель → визуализация. Убедитесь, что правильные классы вообще появляются. Затем добавляйте треки, зоны, время и события по одному этапу.

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

Шаг 8. Испытайте и оформите версию. Сохраните параметры, состав моделей, ассет и результаты. Комментарий «работает» слишком общий; лучше «на версии ассета 1.2 найдены 8 из 9 размеченных эпизодов, 1 ложное событие, пропуск при перекрытии головы» — если именно это измерено.

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

Разделяйте четыре уровня настройки:

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