Такси-парк: телеметрия 60 машин уходит в облако вендора — как забрать поток себе

MAATRIX

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

Как устроена типовая телеметрия таксопарка сегодня

Схема почти всегда одна и та же, независимо от того, кто ставил оборудование. Бортовой блок с SIM-картой в машине собирает данные с GPS-модуля и, если устройство более продвинутое, с диагностического разъёма автомобиля. Дальше по сотовой сети он открывает соединение до сервера производителя — обычно это TCP-сокет на фиксированный IP:порт или, у более новых моделей, HTTP-запросы или publish в MQTT. Сервер производителя принимает поток, разбирает бинарный или JSON-протокол, кладёт в свою базу и рисует вам веб-интерфейс поверх неё.

Вы как таксопарк в этой цепочке — потребитель готового отчёта. У вас есть логин в личном кабинете вендора, может быть — токен для REST API, чтобы вытягивать сводки в свою CRM или систему расчёта зарплаты водителей. Но сырой поток, тот самый набор точек с координатами и таймстампами, который физически генерируют ваши 60 машин, никогда не касается вашей инфраструктуры. Он рождается на ваших автомобилях и умирает в чужой базе.

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

Почему это ваша слепая зона, а не просто неудобство

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

Ограниченная глубина истории. Большинство телематических платформ хранят детальные треки ограниченное время — дальше данные либо агрегируются до сводок, либо удаляются вовсе. Если через полгода понадобится разобрать конкретный рейс по жалобе клиента или для суда по ДТП, а нужной детализации в архиве вендора уже нет — второй попытки не будет.

Единая точка отказа вне вашего контроля. Если сервис вендора ложится (плановые работы, авария в дата-центре, DDoS на его инфраструктуру), вы на это время слепы по всему парку одновременно. Диспетчер не видит, где машины, водители не получают команды на устройство, автоматические алерты по превышению скорости или выходу за зону не срабатывают. Ваш бизнес — такси, а не хостинг, но в этот момент именно чужой хостинг решает, работаете вы вслепую или нет.

Тарифная зависимость. Подписка обычно считается за единицу оборудования в месяц. Когда парк растёт с 60 машин до 90, растёт и счёт — линейно и без права договориться, кроме как через отдел продаж вендора. Отказаться от подписки — значит физически потерять доступ к своим же данным, даже если оборудование продолжает работать.

Смена вендора — с нуля. Если решите сменить производителя оборудования (новая партия машин, более выгодный контракт на обслуживание), история со старой платформы обычно не переносится в новую. У вас остаётся PDF-отчёты, но не сырые треки, по которым можно, например, пересчитать реальный пробег для сравнения с показаниями одометра.

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

Что реально едет в потоке с 60 машин

Возьмём парк из 60 машин как иллюстративный пример — именно с такого масштаба вопрос «а где вообще эти данные» обычно и возникает: слишком много, чтобы отслеживать вручную по вкладкам в личном кабинете вендора, но ещё не тот объём, что требует специализированной big data инфраструктуры.

Типичный набор полей в одной записи телеметрии:

• временная метка события;
• идентификатор устройства/машины;
• координаты (широта, долгота), иногда с точностью и числом видимых спутников;
• скорость на момент фиксации;
• состояние зажигания (включено/выключено) — по этому полю считают моточасы и время простоя;
• пробег по одометру устройства;
• события резкого торможения/ускорения, если блок умеет их детектировать;
• при подключении к диагностическому разъёму — уровень топлива или заряда, обороты двигателя, коды ошибок.

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

Забрать поток на свой сервер: два сценария

Здесь важно понять техническую развилку, потому что от неё зависит, сколько работы предстоит.

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

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

Приёмная часть на вашей стороне в обоих сценариях выглядит похоже. Если устройства умеют HTTP, поднимаете простой веб-сервис — например, на FastAPI:

from fastapi import FastAPI, Request
import asyncpg

app = FastAPI()
pool: asyncpg.Pool | None = None

@app.on_event("startup")
async def startup():
    global pool
    pool = await asyncpg.create_pool(dsn="postgresql://telemetry:pass@localhost/fleet")

@app.post("/ingest/{device_id}")
async def ingest(device_id: str, request: Request):
    payload = await request.json()
    async with pool.acquire() as conn:
        await conn.execute(
            """
            INSERT INTO car_telemetry (device_id, ts, lat, lon, speed, ignition, odometer)
            VALUES ($1, $2, $3, $4, $5, $6, $7)
            """,
            device_id,
            payload["ts"],
            payload["lat"],
            payload["lon"],
            payload.get("speed"),
            payload.get("ignition"),
            payload.get("odometer"),
        )
    return {"status": "ok"}

Если оборудование поддерживает MQTT, вместо самописного HTTP-приёмника проще поднять брокер и подписчика, который пишет в базу:

# docker-compose.yml
services:
  mosquitto:
    image: eclipse-mosquitto:2
    ports:
      - "1883:1883"
      - "8883:8883"
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf
      - mosquitto-data:/mosquitto/data

volumes:
  mosquitto-data:

Оба варианта, и HTTP, и MQTT, держите за TLS — устройства подключаются через мобильный интернет, канал должен быть шифрован хотя бы на уровне транспорта, а порт приёма стоит открывать точечно, под конкретный входящий трафик от устройств, а не как общий вход в сеть. Если часть машин или диспетчерских рабочих мест подключается через VPN, логика правильной сегментации доступа устройств разобрана в статье про IoT-устройства и VPN — принципы там применимы и к бортовым блокам такси.

Когда поток становится заметно больше 60 устройств или к нему добавляются другие источники (шлагбаумы на стоянке, счётчики топлива на АЗС парка), между приёмником и базой имеет смысл поставить брокер сообщений, чтобы приёмник не блокировался на записи в БД и не терял точки при кратковременных просадках — про выбор такого брокера есть отдельный разбор: NATS или Kafka, что выгоднее и когда.

Куда писать данные: база под телеметрию

Телеметрия — это классические time-series данные: много записей с меткой времени, редко обновляются задним числом, читаются в основном по диапазону времени и по машине. Для парка в десятки машин обычной PostgreSQL с индексом по времени и device_id хватает с большим запасом:

CREATE TABLE car_telemetry (
    id          BIGSERIAL PRIMARY KEY,
    device_id   TEXT NOT NULL,
    ts          TIMESTAMPTZ NOT NULL,
    lat         DOUBLE PRECISION,
    lon         DOUBLE PRECISION,
    speed       REAL,
    ignition    BOOLEAN,
    odometer    NUMERIC
);

CREATE INDEX idx_telemetry_device_ts ON car_telemetry (device_id, ts DESC);

Если позже понадобится хранить телеметрию годами и строить по ней аналитику (среднюю загрузку парка по часам, простои, маршруты за месяц), стоит сразу выбирать между PostgreSQL с расширением для временных рядов и ClickHouse, который заточен именно под такие объёмные аналитические выборки — разница между ними и когда какая база оправдана разобраны в статье ClickHouse или PostgreSQL для аналитики. Для 60 машин с горизонтом хранения в один-два года обычной PostgreSQL, скорее всего, хватит без дополнительных расширений — усложнять стек стоит только тогда, когда объём данных и частота аналитических запросов это реально требуют. Пошаговая установка самой PostgreSQL на сервер, если начинаете с нуля, описана в статье как установить и настроить PostgreSQL на VPS.

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

Миграция без простоя: пошагово

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

1. Выясните у сервисной компании или в документации к оборудованию, поддерживает ли устройство настройку целевого адреса. Это определяет, какой сценарий из описанных выше у вас в руках.
2. Поднимите приёмник на отдельном сервере, не трогая пока рабочий канал в облако вендора. Оба потока идут параллельно — старый продолжает кормить текущий дашборд, новый только копится в вашей базе.
3. Переключите 3-5 машин на отправку в ваш сервер (в дополнение или вместо облака, если прошивка поддерживает dual-destination) и сверяйте несколько дней: совпадают ли координаты, не теряются ли точки, нет ли расхождений по одометру.
4. Постройте свой дашборд поверх новой базы и дайте диспетчерам попробовать его в фоне, пока основным остаётся старый — так вы поймаете нехватку каких-то полей или метрик до того, как станете зависеть от нового решения полностью.
5. Переключайте остальные машины пачками, а не все разом — так проще локализовать проблему, если у части оборудования обнаружится нестандартное поведение протокола.
6. Держите подписку на облако вендора активной ещё некоторое время после полного переключения как запасной канал, и только убедившись, что свой приём стабилен на всём парке несколько недель, отключайте её.

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

Частые вопросы