Контроль занятости парковочных мест по камерам

Коротко

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

Что именно нужно определить

Минимальная модель машиноместа включает больше двух значений:

• свободно;
• занято;
• нарушение разметки;
• выведено из эксплуатации;
• статус неизвестен;
• время последнего доверенного наблюдения;
• источник наблюдения;
• при наличии — нормализованный ГРЗ и кадр.

Статус «неизвестно» особенно важен. Если камера отключилась, отсутствие нового сообщения не доказывает свободу. В публичном счётчике такие места должны либо исключаться, либо показываться отдельным качественным показателем.

Пять слоёв контроля места

1. Физическое наблюдение

Камера и её встроенная аналитика определяют границы места, занятость, нарушение и, если поддерживается, ГРЗ. На качество влияют:

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

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

2. Адаптация vendor-протокола

Камеры передают данные по-разному. Нормализующий слой должен:

• проверить обязательные поля;
• связать физический канал с каноническим местом;
• вынести тяжёлый кадр в media storage;
• привести время к согласованной зоне;
• сформировать уникальный ID;
• не отправлять в ядро vendor-specific словарь.

3. Дедупликация и защита от дребезга

Одно физическое событие может прийти несколько раз. Камера повторяет HTTP push, сеть доставляет дубль, heartbeat и recognition конкурируют. Простое «последняя запись побеждает» создаёт мигание и ложную историю.

Нужны правила:

• стабильный event ID или fingerprint;
• подтверждение перехода несколькими наблюдениями там, где это оправдано;
• мягкий и жёсткий refresh неизменного состояния;
• порядок по времени наблюдения;
• защита от старой повторной доставки;
• отдельный lifecycle для started/ended тревог.

4. Доменное состояние и история

Ядро не должно слепо доверять коду места из внешнего payload. Оно проверяет, что место существует и связано с источником. Неразмеченные коды помещаются в quarantine, а не создают тихо новый ресурс.

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

5. Представление и реакция

Оператору нужны не только цвет и номер. Карточка должна отвечать:

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

Для водителя данных должно быть меньше: количество и направление, но не ГРЗ соседнего автомобиля и не внутренние причины отказа.

Основные классы ошибок

Ложная занятость

Тень, человек, тележка или автомобиль в проезде воспринимаются как машина на месте. Последствия — заниженный свободный остаток и неверная аналитика.

Ложная свобода

Часть автомобиля перекрыта или изменилась сцена. Это опаснее для навигации: водитель едет к занятому месту.

Неверный ГРЗ

Статус места может быть корректным, а номер — нет. Эти метрики следует измерять отдельно. Нельзя считать ошибку одной общей accuracy.

Устаревший статус

Источник offline, но UI продолжает показывать старое значение как текущее. Нужны freshness и unknown.

Ошибка привязки

Камера корректно распознала событие, но канал связан с другим местом. Это не ML-ошибка, а конфигурационная. Приёмка должна проверять полный mapping.

Как измерять качество

Сформируйте размеченную выборку:

1. выберите 20–50 мест разных типов и сложностей;
2. снимайте контрольные состояния в часы пик, ночью и при изменении освещения;
3. фиксируйте физический эталонную ручную разметку независимо от системы;
4. разделите классы free, occupied, violation, unknown;
5. отдельно оцените статус и ГРЗ;
6. измерьте задержку от наблюдения до API и UI;
7. сохраните версию встроенного ПО, конфигурацию и период.

Минимальная таблица результатов:

Как событие проходит через CShark

1. IPTronic-камера отправляет статус/recognition payload.
2. Gateway проверяет поля, нормализует ГРЗ, сохраняет кадр в S3 и принимает решение anti-flap.
3. Событие фиксируется в локальном outbox до подтверждения NATS.
4. Core consumer проверяет камеру/канал и место, обновляет PostgreSQL и публикует доменное событие.
5. WebSocket обновляет операторскую карту; история доступна через analytics API.
6. При violation или video analytics инцидент создаётся/обновляется отдельным consumer.
7. Доступность и табло пересчитываются по текущей модели.

Это доказывает программный путь данных. Оно не доказывает точность конкретной камеры до пилота.

Фото, видео и персональные данные

Кадр может содержать ГРЗ, автомобиль, человека и элементы закрытого объекта. Для эксплуатации и маркетингового кейса нужны разные режимы доступа.

Для продукта:

• приватный bucket;
• временные presigned URL;
• permission visits:read для чувствительных данных;
• аудит чувствительного просмотра;
• retention и удаление.

Для публикации:

• письменное право использовать материал;
• размытие лиц, полных ГРЗ, пропусков и экранов;
• удаление EXIF/координат;
• проверка, что фон не раскрывает режимный объект;
• исходник хранится отдельно от публичной версии.

Вопрос о правовом основании должен решать владелец данных и юрист, а не редактор статьи.

Как запустить пилот

Неделя 1: обследование, выбор мест, схема mapping и критерии эталонную ручную разметку.

Неделя 2: установка/подключение, калибровка, проверка времени и сети.

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

Неделя 4: слепая контрольная выборка, latency, отказы и отчёт.

Решение о масштабировании принимайте по классам ошибок, а не по среднему проценту.

FAQ

Сколько мест контролирует одна камера?

Зависит от оптики, высоты, геометрии, разрешения и алгоритма производителя. Универсального числа нет; нужен план покрытия и тест на худших местах.

CShark распознаёт номера сам?

Нет. Текущий CShark принимает готовый результат совместимой камеры/аналитики, нормализует его и использует в бизнес-контуре.

Что происходит при снеге, тени или перекрытии?

Это проверяется на выборке конкретного объекта. Программный слой должен показывать свежесть и неизвестность, а не скрывать деградацию.

Где хранится фото?

В CShark — в S3-совместимом приватном хранилище; клиент получает временную подписанную ссылку при наличии права.

Можно ли использовать существующие камеры?

Если доступен совместимый протокол и камера даёт необходимое качество. Нужны версию встроенного ПО, примеры payload, план покрытия и стендовая/полевая приёмка.

Граница применимости к CShark

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

Посмотрите, какие возможности CShark доступны водителю и оператору и как они применяются на парковке, на странице возможностей системы.