Как PDP Mobile связали со СКУД для шлагбаумов, домофонов и Bluetooth-доступа

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

Шлагбаум может быть исправен, домофон может отвечать, камера может хорошо видеть номер. Но если приложение и СКУД по-разному понимают, кому сейчас можно открыть ворота, система быстро превращается в набор исключений: тут QR-пропуск, там карта жителя, здесь госномер, отдельно Bluetooth.

В PDP Mobile мы связали мобильное приложение со СКУД-системой для физического контроля доступа: шлагбаумы, ворота, домофоны и Bluetooth-доступ. Главная часть задачи оказалась не в кнопке «открыть», а в модели идентификаторов.

Было: доступ есть, единой модели нет

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

СКУД работает с железом: открывает шлагбаум, принимает решение по воротам, обслуживает домофон, проверяет доступ по Bluetooth. Приложение живёт ближе к пользователю: там пропуска, привязанные данные, сценарии входа и выезда.

Самый заметный сценарий — автомобильный. Камера распознаёт госномер, СКУД проверяет, есть ли для него действующий токен, и шлагбаум открывается автоматически. Пользователь не нажимает кнопку, не ищет QR, не звонит диспетчеру. Но для системы это всё равно полноценная проверка прав, а не «номер увидели — открыли».

Рядом с этим живут другие идентификаторы:

• токены QR-пропусков;
• токены номерных знаков;
• карты доступа жителей;
• Bluetooth-доступ с телефона.

Их нельзя было складывать в одну корзину. У каждого типа свой lifecycle: как создаётся, когда становится активным, как валидируется, как отзывается.

Что поменяли в интеграции

Мы завели связку между PDP Mobile и СКУД так, чтобы приложение отвечало за пользовательские сценарии и состояние идентификаторов, а СКУД — за исполнение на физическом уровне.

Если в приложении появляется QR-пропуск, в СКУД уходит токен QR-пропуска с понятными правилами проверки. Если пользователь привязывает автомобиль, СКУД получает токен номерного знака, который потом используется при распознавании камерой. Если нужна карта жителя, она обрабатывается как отдельный тип доступа, а не как «ещё один QR».

Живая деталь с проектирования: очень хотелось сделать общий accessToken и различать всё одним полем типа. На схеме это выглядело аккуратно. Потом дошли до отзыва доступа — и схема перестала быть аккуратной. QR-пропуск, номерной знак и карта жителя отзываются по разным причинам и в разных сценариях. Если замазать различия общей сущностью, ошибки вылезут не в API, а у закрытого шлагбаума.

Поэтому правила валидации и отзыва разнесли по типам идентификаторов. Это менее «красиво» в модели, зато честно отражает поведение доступа.

Стало: приложение управляет доступом, СКУД открывает железо

После интеграции PDP Mobile стал точкой, через которую можно управлять доступом к физической инфраструктуре: шлагбаумам, воротам, домофонам и Bluetooth-сценариям.

Было: доступ существовал в отдельных механиках. QR-пропуск — один сценарий, госномер — другой, карта жителя — третий, Bluetooth — четвёртый. Любое изменение прав требовало аккуратно донести новое состояние до СКУД, иначе пользователь видел одно, а железо решало другое.

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

Автомобильный сценарий стал самым наглядным. Камера распознаёт госномер, СКУД сопоставляет его с токеном номерного знака, шлагбаум открывается автоматически. Для пользователя это выглядит как быстрый проезд. Для нас — как цепочка из распознавания, проверки токена и решения по конкретной точке доступа.

Где пришлось быть аккуратными

В таких интеграциях опасно думать только про успешное открытие. Не менее важны состояния, когда доступ должен перестать работать.

Например, отзыв QR-пропуска не равен отзыву карты жителя. Отвязка госномера не равна отключению Bluetooth-доступа. Все эти действия внешне похожи: «запретить проход». Но внутри это разные сущности, разные проверки и разные последствия для СКУД.

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

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