Безбилетная парковка по госномеру: полный цикл

Коротко

Безбилетный въезд выглядит просто: камера видит номер, шлагбаум открывается. Но номер — только один сигнал. Он ещё не доказывает, что проезд разрешён, команда дошла до контроллера, автомобиль действительно пересёк створ, парковочная сессия открылась, сумма рассчитана, платёж подтверждён, а повторное событие не создало второй визит.

Надёжная система хранит эти этапы раздельно и связывает их корреляционным идентификатором.

Семь подтверждений полного цикла

1. Detection: автомобиль обнаружен

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

Нужны timestamp, lane/device ID и event ID.

2. Identification: получен кандидат ГРЗ

ANPR-камера или внешний сервис возвращает готовый номер, confidence и при необходимости кадр. Система нормализует формат, но не должна превращать сомнительный результат в достоверный.

CShark принимает готовые ANPR-результаты через gateway; собственный ML-движок распознавания в текущем продукте не подтверждён.

3. Decision: вычислено право доступа

Решение учитывает:

• активный субъект/пропуск;
• срок действия;
• разрешённую зону/полосу;
• квоту;
• anti-passback;
• режим объекта;
• ручной или аварийный override;
• приоритет правил и freshness входа.

Ответ должен быть allow или deny с reason code, policy/version и decision ID. «Камера распознала» не равно «можно въезжать».

4. Command: команда поставлена контроллеру

После allow команда может быть queued, затем accepted и executed. Каждое состояние отвечает на отдельный вопрос:

• Core сформировал команду?
• Gateway принял её?
• контроллер выполнил её?
• физический механизм открылся?

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

5. Passage: проезд подтверждён физически

Датчик полосы или контроллер сообщает фактическое пересечение. Только это событие позволяет уверенно менять anti-passback и состояние визита. Команда open без passage может означать, что водитель передумал, механизм заклинило или проехал соседний автомобиль.

6. Session: парковочная сессия открыта или закрыта

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

7. Audit: цепочка расследуема

Оператору нужен не один статус «успешно», а trace:

detection → identification → decision → command → controller result → passage → session.

Для каждого шага сохраняются время, источник, correlation/event ID и безопасно очищенные детали. Без этого спор о въезде решается просмотром разрозненных логов.

Платный выезд добавляет ещё три границы

Тарифный расчёт

Расчёт должен использовать опубликованную версию тарифа и зафиксированные входы: время въезда/выезда, льготу, free minutes, округление, дневной предел или абонемент. Изменение тарифа после начала сессии не должно незаметно менять исторический результат.

Разделите:

• preview — предварительная сумма для интерфейса;
• authoritative calculation — сохранённый расчёт;
• fix/lock — фиксация применённого результата;
• exit approval — разрешение выпускать автомобиль по конкретному основанию.

Платёж

Эквайер или кассовый контур подтверждает оплату. Payment status должен иметь собственный external ID и idempotency. Повторный запрос статуса не должен повторно списывать деньги.

Разрешение выезда

Выезд разрешается не по наличию страницы «Оплата успешна», а по подтверждённому статусу платежа/льготы/абонемента и принятой бизнес-политике. Затем снова выполняется command/result/passage chain.

Важно: тарифный расчёт и платежи — разные подсистемы. В CShark доступны версии тарифов, расчёт и разрешение выезда, но эквайринг, ОФД, чеки и возвраты не входят в текущую поставку.

Архитектура безбилетного контура

Граница особенно важна при интеграции нескольких поставщиков. Контракт должен назвать владельца каждого состояния.

Негативные сценарии

Номер не прочитан

Безопасные варианты зависят от объекта:

• повторный кадр;
• интерком/оператор;
• QR/штрихкод или временный идентификатор;
• билет как резервный контур;
• отказ с понятной инструкцией.

Автоматически подставлять «похожий» номер опасно.

Несколько кандидатов

Система не должна выбирать максимальный confidence без порога и контекста. Нужны ambiguous state и операторская процедура.

Дубликат события

Одинаковый event ID обрабатывается идемпотентно. Повтор с новым ID, но тем же passage, требует временного окна/корреляции — без потери реального второго автомобиля.

События пришли не по порядку

Passage может дойти раньше command result, а gateway — восстановиться после offline. State machine должна выдерживать late arrival и не переписывать более новое состояние старым.

NATS или сеть недоступны

Edge gateway хранит уже принятое событие на диске, повторяет доставку после восстановления и контролирует переполнение. В CShark этот механизм реализован SQLite outbox; допустимая длительность автономности зависит от размера диска и потока.

Контроллер не ответил

Статус команды остаётся неопределённым/ошибочным; оператор видит причину. Слепой retry физической команды запрещён без vendor-safe semantics.

Шлагбаум открылся, но проезда нет

Сессия не должна автоматически становиться подтверждённой только по command success. После timeout выполняется закрытие механизма и no-show policy.

Проезд «хвостом»

Нужны датчики и политика anti-tailgating. ANPR одного автомобиля не подтверждает число физических проездов.

Fire/manual mode

Аварийная политика имеет явный приоритет, автора/источник и аудит. После возврата в normal нужна resync, а не продолжение старого pending command.

Нет применимого тарифа

Система не должна придумывать сумму. Нужны deny/manual-review/zero-policy только по заранее утверждённому правилу и запись в аудит.

Данные и приватность

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

• карта целей и оснований обработки;
• роли владельца/оператора данных;
• минимальный состав payload;
• сроки хранения отдельно для online state, инцидента, финансового документа и техлога;
• object scope и чувствительные permissions;
• защищённые media links;
• маскирование в UI/exports/logs;
• процедура запросов субъекта и инцидента ИБ;
• обезличивание тестов и маркетинговых кейсов.

Эта статья не заменяет правовое заключение по конкретному объекту.

План пилота

Шаг 1. Зафиксировать границы

Одна полоса въезда и выезда, конкретные камеры/контроллеры, синтетические тестовые ГРЗ, тестовый тариф без реального списания или платёжный sandbox.

Шаг 2. Согласовать state machine

Перечислить события, владельцев, timeouts, retries, reason codes и ручные действия. Утвердить, когда начинается и заканчивается сессия.

Шаг 3. Собрать эталонную выборку

День/ночь, загрязнение, разные форматы номеров, мотоциклы, два автомобиля, tailgating, no-show. Значение согласованный размер выборки и доверительный интервал согласовать со специалистом по измерениям.

Шаг 4. Пройти happy и failure paths

Минимум:

• permit allow;
• deny;
• unreadable/ambiguous;
• duplicate/redelivery;
• controller timeout;
• broker/network outage + recovery;
• no-show;
• manual/fire;
• отсутствующий тариф;
• ненулевой расчёт в sandbox;
• повтор проверки платежа без повторного charge;
• exit passage.

Шаг 5. Подписать доказательные материалы

Event trace, UI, физическое видео, версии/версию встроенного ПО, timestamps, дефекты и исключения. Клиентские номера и лица должны быть удалены или закрыты.

KPI пилота

• доля идентификаций с эталонную ручную разметку, отдельно unreadable;
• false allow и false deny;
• decision latency p50/p95/p99;
• command acceptance/execution/passage latency;
• orphan decisions/commands/sessions;
• duplicate session rate;
• доля ручных вмешательств;
• recovery time и backlog drain после outage;
• throughput полосы и очередь — при стабильных внешних условиях;
• расхождение preview/authoritative/final amount;
• спорные операции и время расследования.

Нельзя переносить результат одной полосы и одной недели на любой объект без оговорки.

FAQ

Можно ли полностью отказаться от билета?

Технически да, если согласованы fallback для unreadable/ambiguous, спорных операций и отказа сети/оборудования. На части объектов резервный QR/билет снижает операционный риск.

Что делать с грязным или закрытым номером?

Не выдавать сомнительный результат за точный: повторный кадр, альтернативный идентификатор или оператор по регламенту.

Работает ли система без интернета?

Локальный контур может работать автономно, если ANPR, access, controller и данные находятся на объекте. Облачный эквайринг или внешняя база пропусков создают отдельную зависимость. CShark имеет on-prem/air-gap профиль для Ubuntu AMD64, но полный состав пилота нужно проверить.

Нужен ли anti-passback?

Если один пропуск/номер не должен одновременно находиться внутри и снаружи или повторно въезжать, нужен. Он должен обновляться по подтверждённому passage, а не только по команде.

CShark принимает оплату?

Нет. В текущей версии доступны тарифный расчёт и разрешение выезда, но платежи, эквайринг, ОФД, чеки и возвраты не входят в поставку.

Какую точность распознавания можно обещать?

Только измеренную на репрезентативной выборке конкретной камеры, места установки и условий. CShark не заявляет универсального процента для всех камер и объектов.

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

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

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