Распределённая архитектура

Зачем парковке сервер точного времени

Время участвует в тарификации, anti-passback, видеофиксации, фискальных событиях и восстановлении после отказа. Если устройства живут по разным часам, единая парковочная сессия распадается на противоречивые записи.

Одна минута может изменить деньги и доказательства

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

ТарифГраницы интервалов

Бесплатное время, округление, дневные и ночные правила зависят от согласованной шкалы.

БезопасностьПоследовательность событий

Anti-passback и шлюз требуют правильного порядка въезда, зоны и выезда.

ВидеоПоиск доказательств

Кадр должен совпадать с транзакцией и командой оборудования.

АудитДействия оператора

Без общего времени невозможно надёжно восстановить причины ручного открытия.

Практичная архитектура точного времени

  1. UTC внутри системы. Хранить события в единой шкале, а локальное время и переходы показывать на уровне интерфейса.
  2. Два или более источника. Центральные серверы синхронизируются с доверенными NTP-источниками; контроллеры, кассы и камеры — с локальными серверами объекта.
  3. Локальная доступность. Устройства не должны зависеть от выхода в интернет. NTP внутри технологической сети продолжает отвечать при разрыве внешнего канала.
  4. Резервный режим. При потере первичных источников выбранный узел поддерживает согласованное локальное время, а система явно фиксирует снижение качества синхронизации.
  5. Мониторинг. Контролируется не только доступность NTP, но и фактическое отклонение каждого критичного устройства.

NTP Project описывает режимы server, peer и локальные источники; промышленные реализации поддерживают orphan/local mode, позволяющий сети сохранить единую шкалу при недоступности первичного источника. Это не делает время абсолютно точным, но предотвращает расхождение устройств друг с другом.

Как парковка должна продолжать работу без связи

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

ФункцияOffline-поведениеПосле восстановления
Разовый въездЛокально выпускается уникальный билет или создаётся сессияСобытие передаётся с исходным временем и идентификатором устройства
АбонементПроверяется локальный список и допустимый режим anti-passbackКонфликты состояния разбираются по политике приоритета
ОплатаРазрешаются только заранее согласованные способы и рискиТранзакции сверяются с кассовым и банковским контуром
Шлюз / безопасностьЛокальная логика датчиков и блокировок сохраняетсяПередаются тревоги и ручные операции
НавигацияПоказывается последнее подтверждённое состояние или безопасное сообщениеСчётчики и карта пересчитываются по фактам
Offline — это ограниченный режим, а не полная копия центра

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

Почему простая отправка накопленных логов недостаточна

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

Если две зоны независимо изменили состояние одного идентификатора, применяется заранее согласованная политика: приоритет физического проезда, ручная проверка, блокировка следующего использования или восстановление по LPR и видео. Молчаливое «последняя запись победила» опасно для выручки и безопасности.

Роль CShark в общей временной модели

CShark связывает с событием место, камеру, время, кадр и состояние обработки; показывает время последнего подтверждения места и оборудования. Поэтому камеры, сервер CShark и внешняя АПС должны использовать согласованные источники времени. Тогда можно доказательно сопоставить команду шлагбаума, проезд, появление автомобиля на месте и последующий выезд.

При потере наблюдения CShark показывает последнее подтверждённое состояние и затронутые места. В проекте это помогает не выдавать устаревшую информацию за текущую и правильно организовать деградацию навигации.

Чек-лист приёмки

  • все серверы, камеры, кассы и контроллеры синхронизируются с утверждённой иерархией NTP;
  • часовой пояс и переходы не меняют сохранённые UTC-метки;
  • есть предупреждение об отклонении часов и журнал изменения времени;
  • проверен внешний разрыв связи и отказ локального NTP;
  • устройства сохраняют последовательность и уникальность offline-событий;
  • после восстановления нет двойных сессий, платежей и ложного anti-passback;
  • отчёты позволяют различить время события и время поступления на сервер.

Источники и документация

Проверим отказоустойчивость парковки

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

Интеграция и отказоустойчивость