Как мы следим за 18 000 автомобилями одновременно: телеметрия каршеринга изнутри

Два года назад мы уже писали на Хабре про телеметрию — тогда речь шла о том, как мы тестировали её через эмулятор, потому что вручную собирать JSON-пакеты для каждого тестового кейса было трудно. С тех пор система выросла на порядок: на момент этого материала парк — 18 000+ машин, а телеметрия из «источника данных для отдельных фич» превратилась в нервную систему всего сервиса. Без неё мы не могли бы удалённо управлять машиной, знать, где она стоит, и понимать, что с ней происходит прямо сейчас.

В этой статье — про то, как это устроено сегодня: сколько данных генерирует парк, почему GPS в городе периодически выдает неточные данные (и при чём тут машины, «плавающие» по Неве), как мы построили свою систему валидации координат Geomio и куда всё это движется дальше.

Масштаб: 216 миллионов пакетов в сутки

Каждый автомобиль в парке передаёт данные примерно раз в 7–8 секунд — это около 12 000 пакетов телеметрии в сутки с одной машины. Умножьте на 18 000+ автомобилей — и получится порядка 216 миллионов пакетов в день. Это не батчи, которые прилетают раз в час, а непрерывный поток, который система принимает и обрабатывает практически в реальном времени: пакеты уходят в Kafka-топики и оседают в ClickHouse, откуда их поднимают зависимые сервисы — мониторинг состояния, биллинг, поиск машин в приложении.

Отдельная инженерная задача — разнородность парка. У нас одновременно эксплуатируются машины с разными телематическими блоками, и наивным решением было бы писать отдельную интеграцию под каждую комбинацию «марка + блок». Мы пошли другим путём: в основе — единая платформа с микросервисной архитектурой, единая логика и единая прошивка, а под особенности конкретного телематического блока делаются точечные доработки. То есть специфика остаётся на уровне работы с самим блоком, а всё, что выше — мониторинг, диагностика, продуктовые сценарии — работает по одним и тем же правилам независимо от того, какая машина прислала пакет. Для инженеров, которые сталкивались с классической проблемой фрагментации в IoT-парках (когда N типов устройств требуют M интеграций и в итоге получается N×M кода), это, кажется, рабочий паттерн: изолировать вариативность на границе системы, а не размазывать её по всей архитектуре.

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

Когда GPS выдает не точные данные: 15% отказов и машины в реке

Один из самых ярких кейсов — машина, которая за 15 минут «переплыла» Финский залив из Кронштадта в Пулково, физически стоя на месте.

Проблема с глушением GPS не экзотическая — с ней сталкивается любой каршеринг. Плотная городская застройка, тоннели, подземные парковки, отражение сигнала от зданий — всё это регулярно портит координаты. Если смотреть на причины отказов пользователей за последний год, ситуация, когда автомобиль не получается найти по отображаемым координатам, — это около 15% всех отказов. Для пользователя это сорванная поездка и негативный опыт здесь и сейчас. Для бизнеса — простаивающий автомобиль, который продолжает генерировать расходы, и, если его приходится искать вручную, дополнительные операционные затраты сверху. Именно поэтому точность геопозиции — метрика, напрямую влияющая на юнит-экономику сервиса, и мы системно работаем над тем, чтобы её снижать — Geomio, о котором дальше, один из инструментов именно для этого.

Про инструмент Geomio

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

Идея в том, чтобы не полагаться на один источник истины, а сопоставлять несколько: координаты с мобильного устройства пользователя, данные телематического блока автомобиля, в перспективе — координаты исполнителя, а также данные, которые может ввести оператор или сам пользователь в приложении. На основе этого сопоставления Geomio принимает решение, можно ли доверять конкретной координате. Если да — она идёт дальше по пайплайну; если нет — отбрасывается, чтобы система не строила решения на заведомо ошибочных данных.

Важный нюанс для тех, кто проектирует похожие системы: задача Geomio — не заменить GPS более точным источником, а повысить качество данных, с которыми работает вся телематика, за счёт межисточникового консенсуса. Это особенно окупается в сложных городских условиях — как раз там, где один источник почти гарантированно соврёт. Сейчас Geomio уже используется в ряде продуктовых сценариев и продолжает расширяться по мере накопления данных.

Внешние помехи — уже не бытовая проблема, а постоянная борьба

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

Мы развиваем это в двух направлениях. Первое — расширяем число источников координат: помимо GPS от телематического блока и мобильного приложения, тестируем альтернативные источники, например Semitsvet Geo. Второе — постепенно переносим часть логики валидации непосредственно в телематический блок, то есть ближе к границе системы. Это классический edge-подход: меньше зависимости от связи с бэкендом и быстрее реакция на месте, что критично, когда решение нужно принять до того, как машина успеет «уехать» на несуществующие координаты в приложении пользователя.

Предиктивная диагностика

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

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

Телеметрия и безопасность: осознанный отказ от скоринга водителей

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

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

Куда это движется

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

• Защита от подмены координат. Спуфинг и подавление GPS-сигнала — уже не единичные инциденты, а фактор, с которым приходится постоянно работать любому сервису, завязанному на геопозицию в городе.

• Модели доверия к геопозиции. Развитие логики, лежащей в основе Geomio, — от бинарного «доверяем / не доверяем» к более гибкой оценке источников.

• Перенос логики в телематический блок. Меньше зависимости от бэкенда, быстрее реакция на аномалии на месте.

• Предиктивная диагностика. Пока в проде — реактивные уведомления, но накопленная телеметрия — это фундамент для перехода к прогнозу поломок.

Интересный факт

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

Если вы тоже работаете с геоданными, IoT-парками или валидацией данных из недоверенных источников — интересно сравнить подходы в комментариях. А если видели GPS-спуфинг не в теории, а в проде — тем более расскажите, как боролись.