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

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

Если вы разрабатываете софт для IoT, пишете мобильные приложения, проектируете распределённые системы или просто любите истории о том, как инженерные костыли превращаются в полноценные решения — эта статья для вас.

Мы разберём:

• что делать, когда у вас есть 10 000 устройств с Bluetooth, но вы не знаете их паролей;

• как тестировать прошивки на умном чайнике;

• почему в итоге пришлось строить отдельные сервисы конфигурации команд;

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

Поехали ??

Как мы научили каршеринг работать без интернета: предыстория про Bluetooth, дачи и слабый сигнал

Пользователи могут ездить на машинах Ситидрайва в радиусе до 2500 км от города аренды, заезжая в разные места — на дачу, в лес за грибами или на цифровой детокс с палаткой в поле. В таких локациях часто плохо ловит мобильная сеть. Из-за этого блок управления машины не всегда может связаться с сервером, чтобы открыть или закрыть двери, и связь пропадает.

Телефон клиента ещё может поймать локальный Wi-Fi, но телеметрический блок машины — увы, нет. На этот случай мы оснастили все автомобили каршеринга Bluetooth-модулем, способным принимать команды напрямую с телефона клиента, у которого активна аренда. Интернет на стороне машины при этом не нужен.

Как мы искали ключи к своим же модулям

Когда я пришёл в Ситидрайв чуть больше трёх лет назад, первая задача, которую мне поставили, звучала примерно так:
«У нас в 10 000 машинах стоят Bluetooth-модули, у поставщика есть документация с их параметрами… но вот какому автомобилю соответствует какой модуль — неясно. Нужно навести порядок».

К тому моменту внутри компании уже запустили эксперимент: сервисное приложение для специалистов по обслуживанию получило встроенный Bluetooth-сканер. Логика была простая — раз сотрудники каждый день взаимодействуют с машинами (заправка, мойка и прочие регламентные работы), то приложение на фоне может автоматически сканировать эфир и пытаться «сопоставить» модули с записями из документации.

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

Как умный чайник помог нам перепрошить 10 000 машин

У модулей имелся внутренний режим конфигурирования, доступный только авторизованным специалистам. Правда, для этого требовалось разработать отдельный инструмент. Мы выбрали Android, и я написал инструмент для безопасного обновления настроек модулей.

Первая стадия разработки выглядела довольно забавно. Чтобы не снимать с линии реальные автомобили и не гонять инженеров впустую, я отлаживал интеграцию у себя дома — на умном чайнике. У него тоже был Bluetooth и две команды: включить и выключить. В общем, двери он не открывал, но свою роль «тестового стенда» сыграл отлично.

Когда приложение заработало стабильно, пришло время для самого масштабного этапа — перепрошивки всего автопарка. На тот момент (2022 год) это было свыше 10 000 машин в трёх городах.

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

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

Как мы перевели автопарк на новые Bluetooth-модули

Клиенты активно пользовались Bluetooth-управлением, инженеры радовались стабильности. Но в этом году пришли коллеги из автопарка и сообщили:
«Ребята, производитель выкатывает новые модули, а там протокол меняется».

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

Апгрейд, который даёт новые вызовы:

• Жёстко зашитые команды в приложениях. В мобильных клиентах логика open/close была прописана напрямую, без вариантов.

• Разные автопроизводители — разные схемы. На одних машинах сигнал «открыть» шёл в первый выход, на других — во второй или третий. Новый протокол требовал под это всё подстраиваться.

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

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

2. Клиентское приложение теперь не содержит в себе команды, а получает с сервера.

3. Архитектуру сделали универсальной: новые сервисы поддерживают и старые модули (open/close), и новые с их «гибкими» цифровыми выходами.

Стенд тестирования. 

Для сервисного приложения хватало и умного чайника — там можно было поиграться с Bluetooth и базовой логикой. Но когда речь зашла о клиентском приложении, тестировать его без реальной машины полноценно невозможно. Да и команда разработки у нас распределена по всей России, а машины есть только в 6 городах присутствия сервиса.

Чтобы решить эту проблему, инженер по дополнительному оборудованию сделал для нас универсальное решение — компактную «коробочку». В неё подключаются Bluetooth-модули, и при отправке команд, светодиоды показывали статус выполнения команды.

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

Отслеживаем использование

Чтобы понять, как на самом деле используется Bluetooth, мы завели мониторинг и вывели метрики в Grafana. На графиках сразу видно: с выходом версии 5.4 (где появилась расширенная поддержка Bluetooth) число таких операций стало расти вместе с обновлением приложений у пользователей.

Как только у клиента пропадает мобильная связь, графики фиксируют всплеск активности через Bluetooth.

Архитектура без «жёсткой команды»

Запрос сначала проходит через промежуточные сервисы — там происходит аутентификация, проверка заказа и прочие необходимые шаги. До нас доходит уже обезличенный запрос на конкретную конфигурацию для машины. Это важно: лишние клиентские данные не кочуют по сервисам, где они не нужны.

Главный плюс подхода в том, что мы ушли от жёстко зашитой бизнес-логики в приложении к централизованному управлению через сервисы. Теперь, если производитель снова решит «порадовать» неожиданным изменением протокола, нам не придётся выкатывать несколько релизов мобильного клиента ради одной команды — достаточно поправить конфигурацию на сервере.

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

Какой урок?

Наша история с Bluetooth-модулями — это частный случай куда более широкой задачи. В IoT-мире устройства разные, протоколы быстро меняются, а сеть пропадает именно тогда, когда она нужна больше всего.

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

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

В конечном счёте, гибкая архитектура — это не просто удобство для разработчиков. Это то, что напрямую превращается в устойчивость сервиса и спокойствие пользователей.