CAR AI

Road AI Monitoring

Дизайн-док: “Умный мониторинг дорог”

Цель и KPI

Цель: автоматизировать выявление и учет дефектов дорожной инфраструктуры с помощью авто-комплекса (камера + edge-компьютер + GNSS) и диспетчерского веб-дашборда.
KPI пилота (пример):

Recall по ключевым дефектам (яма/мусор/знак) ≥ 0.80 на тестовых маршрутах
Precision событий (после фильтров и подтверждения) ≥ 0.85
Время доставки события в дашборд: 5–30 сек при наличии связи
Дедупликация: ≤ 1–2 события на один дефект за один проезд
Доступность сервиса (backend+dashboard): ≥ 99% в пилоте (реально)

Объем MVP и “Оптимальный лучший” вариант

MVP (8–12 недель)

Дефекты:

Ямы/выбоины (детекция bbox → позже сегментация)
Мусор/предметы на дороге (детекция bbox)
Дорожные знаки: “поврежден/наклонен/отсутствует” (этапно, см. ниже)

Функции:

Авто-событие: фото + координаты + тип дефекта + важность + уверенность
Дашборд: карта + журнал + карточка дефекта + статусы + назначение исполнителя + выгрузка
Оптимальный “профессиональный” вариант (сразу закладываем в архитектуру)Edge-инференс на Jetson Orin (устойчиво, энергоэффективно)
Экспорт модели в TensorRT
Фильтрация/трекинг/дедуп на борту
Бэкенд: event pipeline + хранилище медиа + аудит + роли
Карта: слои/кластеры/фильтры, “оперативный журнал” как первичная сущность

Архитектура (схема модулей)

2.1. Бортовой комплекс (Edge)

Компоненты:

Камера(ы) → поток видео
GNSS (GPS/ГЛОНАСС) + время
Edge-компьютер (Jetson) + SSD
Модуль инференса (YOLO det/seg)
Модуль событий (фильтр/трекинг/дедуп)
Модуль отправки (LTE/5G), очередь offline

Задачи борта:

детектировать дефект
подтвердить по нескольким кадрам
собрать событие (метаданные + фото/клип)
отправить на сервер
при отсутствии связи — сохранять и “догружать”

2.2. Backend

API приема событий (REST/GraphQL по выбору)
Очередь/стрим (на вырост): RabbitMQ/Kafka (в MVP можно без Kafka, но с очередью задач)
Хранилище медиа: S3-совместимое (MinIO/облако)
База данных: PostgreSQL (+ PostGIS для гео)
Сервис дедупликации на карте (объединение событий в “дефект на местности”)
Сервис пользователей и ролей (RBAC)
Аудит/логирование
Экспорт отчетов (CSV/XLSX), интеграции (опционально)

2.3. Dashboard (Web)

Карта (кластеры, фильтры, слои)
Оперативный журнал (таблица с быстрыми действиями)
Карточка дефекта (медиа, история статусов, комментарии, исполнитель)
Панель аналитики (минимум: количество по типам/районам/периодам)

Модель данных (ключевые сущности)

3.1. Event (сырое событие от машины)id, timestamp_utc

vehicle_id, device_id
lat, lon, heading, speed
defect_type (enum)
severity (S1–S4)
confidence (0..1)
media_original_url, media_annotated_url (опц.)
model_version
status_raw: NEW / DROPPED (если отфильтровали сервером)

3.2. Defect (объект на местности — результат дедуп/слияния)defect_id

centroid_lat/lon, road_id (если есть)
defect_type, max_severity
first_seen, last_seen
events_count
current_status: NEW / CONFIRMED / IN_WORK / FIXED / REJECTED
assigned_to, SLA_deadline (опц.)
comments, attachments (after-fix photo)

3.3. JournalEntry (оперативный журнал)запись, связанная с Defect

кто/когда подтвердил
кому назначено
действия/решения/комментарии
связи с внешними системами (опц.)

ML: стратегия обучения и качества

4.1. Что обучаем

YOLO детекция: ямы, мусор, знаки (как объект)
Этап 2: YOLO сегментация для ям (маска дает точнее “площадь”)
Для “знак поврежден/наклонен/отсутствует”:

шаг 1: детектируем знак
шаг 2: классифицируем состояние по crop (маленький классификатор)
“отсутствует” чаще решается сравнением с эталонной инвентаризацией/ГИС (если есть), иначе моделью это сложно доказать

4.2. Данные и разметкаИсточник: видео с проездов + выборка кадров (1–2 fps) + балансировка