Привет! Меня зовут Евгений Титов, и я занимаюсь разработкой сервисов телеметрии в каршеринг-сервисе Ситидрайв. В этой статье расскажу о том, что из себя представляет телеметрия в каршеринге, какие сложности возникают при её тестировании, и как мы их решаем.
Что такое телеметрия
Телеметрия в каршеринге – это набор данных, который мы получаем о машине, например, геокоординаты, скорость, пробег, уровень топлива, статус дверей, состояние датчиков на приборной панели. На их основании мы запускаем процессы, например:
уровень топлива ниже определённого значения – ставим задачу на заправку авто;
скорость движения автомобиля выше допустимого значения – уведомляем клиента и службу безопасности о нарушении;
попадание машины на штрафстоянку (да, не все наши клиенты соблюдают ПДД и, бывает, наши машины увозят на штрафстоянки), соответственно, мы снимаем машину с линии, чтобы она была недоступна для клиентов и ставим задачу на вывоз машины.
Как используем данные телеметрии для улучшения сервиса
В Ситидрайве мы заботимся о безопасности и комфорте всех участников дорожного движения – как каршероводов, так и других водителей, поэтому строго относимся к нарушениям ПДД. Благодаря системе телеметрии мы отслеживаем скорость, что позволяет стимулировать пользователей к более спокойному и безопасному вождению, так как за 2 превышения скорости 140 км/ч система автоматически блокирует аккаунт. Кроме того, эти данные используются для индивидуальной настройки стоимости поездок.
Но после введения GPS-глушилок в Москве, данные могут приходить со сбоями. Например, мы заблокировали одного «злоумышленника», который дважды превысил скорость. В его случае, как выяснилось, GPS-сигнал был заглушён и на экране отображалась скорость 512 км/ч, хотя машина стояла на парковке! У меня тоже была подобная ситуация, когда по GPS зафиксировали скорость 360 км/ч, хотя у арендованного автомобиля и близко не было такой мощности.
Также отображаемые в реке машины для нас уже обычная ситуация, с которой мы научились справляться в Москве.
Но буквально недавно столкнулись с таким кейсом в Кронштадте – за 15 минут автомобиль проплыл через Финский залив и оказалась в Пулково. Несмотря на то, что физически машины стояла на месте.
В таких случаях мы применяем свои алгоритмы – считаем расстояние между локациями и время, за которое можно проехать. Например, если машина проезжает 200 км за 3 минуты, то координаты не валидны. Поэтому тестировать подобные кейсы для нас очень важно.
Как тестировать телеметрию
В нашем случае многие кейсы просто невозможно протестировать на реальной машине, например, мы не будем умышленно загонять авто на штрафстоянку или превышать скорость. Команда тестирования для эмуляции этих и других кейсов занималась ручным формированием пакетов телеметрии, которые отправляли в Kafka топики. Число параметров в пакете доходит до 50, поэтому для проверки приходилось тратить около 30 минут только на внесение данных. Формируемые JSON пакеты были очень неудобны для работы.
Решение – эмулятор
Чтобы решить проблемы тестирования, мы решили разработать эмулятор. Теперь сотрудник может выбрать автомобиль и, используя кнопки «вперёд», «назад», «влево», «вправо» и другие параметры, создавать пакеты телеметрии. Таким образом, система подобно реальной машине по заданию тестировщика передаёт данные по всем зависимым сервисам.
По backend части наше новое приложение встало перед сервисом Receiver, который обрабатывает и обогащает полезными данными поступающие пакеты, отправляя их дальше в связанные сервисы:
Monitoring получает обогащённый пакет и решает, надо ли по нему создавать какие-то задачи на обслуживание автомобиля;
ClickHouse – хранилище данных, где мы долгое время храним всю информацию, которая поступает с наших машин.
Весь веб-интерфейс в корпоративных стандартах компании нужно было разработать на React. Но нюанс заключался в том, что команда, которая занимается системами телеметрии, состоит исключительно из backend разработчиков. Для решения проблемы можно было привлечь коллег из других команд, но мы решили пойти альтернативным и современным путём – создать frontend с использованием GPT модели.
И здесь спасли нейросети
Первым на ум пришёл ChatGPT, но его использование проблематично: нужны прокси, оплата и так далее. Яндекс на мой запрос выдавал сообщение, что пока не умеет программировать.
А вот GigaChat мне действительно понравился. Я задавал вопрос: «Сделай на React handler, который получает с формы поля, и отправь их POST запросом на сервер». Сервис выдавал годный код, который я немного модернизировал, зная только основы React. Возможно, есть моменты, которые ещё можно оптимизировать, но для MVP проекта для внутреннего использования модель оказалась очень удобна.
Я выделял по 1-2 часа в день на проект по остаточному принципу и реализовал его за неделю. Если бы я писал это самостоятельно, то скорее бы делал то же самое в 2 раза дольше.
Планы по развитию
Создание максимально точного эмулятора автомобиля, который бы полностью заменил реальные испытания, возможно, но для специфических кейсов всё же лучше провести тест на реальной машине. Ошибка в коде может привести к непредвиденным последствиям, а живая машина — это живая машина с её особенностями и нюансами. Поэтому докручивать эмулятор до полноценного авто пока не имеет смысла.
Я хотел дополнительно реализовать возможность задавать точки А и Б, чтобы маршрут автоматически строился сервисом 2ГИС. Однако, оказалось, что для большинства тестировщиков это не самая приоритетная задача, ведь они сами могут «добраться» до нужного места. Их больше интересуют данные от дополнительных датчиков, таких как скорость с колёс (CAN) и скорость GPS. Поэтому сейчас мы уделяем внимание доработке этих функций. Мы уже можем смоделировать ситуацию, когда в машине не закрылся замок или дверь, и проверить, что система распознает это состояние и отображает информацию о машине. Если открыта дверь – формирует заказ на выезд техника, если открыт центральный замок – отправляет команду на закрытие дверей.
Результаты
Новая эмулируемая среда очень упростила работу тестировщиков. Формирование JSON-файла с 20-30 минут сократилось до пары секунд. Это не только значительно ускорило процесс разработки, но и сделало тестовую среду более приближённой к проду. Например, теперь у нас есть виртуальные заправки. В тестовой среде, чтобы не заставлять тестировщиков мучиться с JSON-файлами, ранее был реализован радиус действия – машина должна находиться в пределах 100 километров от колонки, чтобы её можно было заправить. В реальной же среде этот радиус был меньше, что создавало несоответствие. В эмуляторе мы докрутили расстояние до стандартных 200м, что сделало тестовую среду более точной.
В результате мы получили возможность быстро выявлять ошибки и внедрять новые функции. Сейчас мы работаем над расширением функционала эмулятора, добавляя новые поля.