Немногим более года назад я приступил к разработке бэка для сервиса GPS‑мониторинга автотранспорта. Задача казалась интересной — мне всегда больше нравилась связка с реальным железом и техникой, чем обычный SaaS в вакууме. Бек должен был парсить TCP пакеты по протоколам Galileosky, Vega, Wialon.

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

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

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

Простое и очевидное: скорость и высота

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

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

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

Продолжением идеи с высотами стала фильтрация по перепаду высот между точками с учётом расстояния между ними. 14 метров на 100 метров пути — такое ограничение я вывел. Да, могут срезаться выезды в горы на подготовленных машинах, но этими случаями можно пренебречь.

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

LBS: якорь в реальном мире

Следующее, что лежит на поверхности — LBS: данные той сотовой вышки, с которой сейчас работает трекер, можно настроить чтобы пакет включал в себя её id и примерное расстояние от трекера до вышки. Но трекеры присылают только id вышки, её координаты предстоит получить самому. Готовую базу тоже можно найти, но покрывает она не все вышки в РФ, поэтому пришлось искать стороннее API для пополнения базы (у Google есть такой сервис, несколько сотен запросов в день — бесплатно). Первоначальный вариант, когда процессор ждал ответа от API, оказался порочен: если API по каким‑то причинам замолкал — трек терялся, а архивы выгружались трекерами очень медленно. Пришлось развязывать этот узел: организовывать очередь и прокидывать точку дальше, не дожидаясь ответа, а ответом уже пополнять свою БД.

Далее просто: считаем расстояние от GPS‑точки до вышки и определяем, реальна ли она. В этом вопросе есть тонкости — данным о вышках однозначно доверять нельзя, поэтому, чтобы не терять реальные точки, со временем пришлось внедрить систему адвокатов для точек. О ней будет ниже.

«Сырое» озарение

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

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

Телепорты

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

Джокер: CAN‑шина

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

Так как спуфинг на данные CAN никак не влияет, их получилось применить сразу в нескольких фильтрах: сравнение OBD‑ и GPS‑скорости, перемещение без роста одометра, движение по GPS при нулевой obd скорости или вовсе с заглушенным двигателем.

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

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

Заморозка координаты

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

У заморозки координат есть ещё одна причина — трекеры Vega при определении невалидности координат по базовым настройкам замораживают последнюю точку, которую они считают правдивой.

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

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

Заморозка в ложной точке и адвокаты.

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

Вход в такой кластер ловится физикой: скачок в разы больше того, что допускает прирост одометра. А вот выход из режима — самая интересная часть. Мерить геометрию от последней «доверенной» точки нельзя: если день начался под воздействием, доверенная точка сама ложная, и честное продолжение трека с ней никогда не согласуется — так можно зарезать весь день. Поэтому выход — только через адвокатов самой точки: либо спутниковая и CAN‑скорость согласуются (теоретически они могут совпасть, но шанс у ложной точки на это не велик), либо точная сотовая вышка подтверждает координату. Есть адвокат — точка реальна, режим закрыт.

У подхода есть ограничение — эвакуатор: одометр стоит, координата уезжает. Такой трек покажет стоянку в точке погрузки до первого адвоката.

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

Подмена времени

Самый коварный тип воздействия из встреченных. Кадры приходят с ложным timestamp — проштампованные прошлым или будущим. Сортировка по времени, на которой стоит вся обработка, перемешивает честные и фейковые кадры в одну кашу, и дальше весь конвейер работает по испорченной последовательности. Помните дубли времени из начала статьи, списанные на техдолг? Теперь они предстали в новом свете.

Улика — снова одометр: по реальному времени он монотонно неубывающий. Кадры с подменённым временем выпадают из этой монотонности. Первая версия решения опрашивала соседей — своего рода кворум. Работало, пока кластер фейков не оказывался длиннее окна опроса: фейки внутри кластера голосуют друг за друга. Помогла классика алгоритмов: самая длинная неубывающая подпоследовательность одометра (LIS, O(n log n)) — это и есть «большинство» честных кадров, всё, что в неё не вошло, — под нож. Равные значения включаются, поэтому плато стоянок не режется; точки без одометра проходят насквозь — машины без CAN не трогаем — оставляем для них лазейку.

На момент написания статьи фильтр выглядел так:

private filterOdometerOutliersByMajority(
    points: TrackPointEntity[],
  ): TrackPointEntity[] {
    if (points.length < 3) return points;

    const odoOf = (p: TrackPointEntity): number | null => {
      if (p.odometer_km == null) return null;
      const v = Number(p.odometer_km);
      return Number.isFinite(v) && v > 0 ? v : null;
    };

    // Индексы точек с валидным одометром в порядке следования массива.
    const valid: { idx: number; odo: number }[] = [];
    for (let i = 0; i < points.length; i++) {
      const o = odoOf(points[i]);
      if (o != null) valid.push({ idx: i, odo: o });
    }

    // LIS (неубывающая) по valid[].odo. tails[k] — индекс в valid хвоста
    // подпоследовательности длины k+1 с наименьшим одометром; prev[i] — предок
    // элемента i в цепочке (для восстановления).
    const n = valid.length;
    const tails: number[] = [];
    const prev = new Array<number>(n).fill(-1);
    for (let i = 0; i < n; i++) {
      const v = valid[i].odo;
      // upper_bound: первая позиция, где хвост СТРОГО больше v (равные включаем).
      let lo = 0;
      let hi = tails.length;
      while (lo < hi) {
        const mid = (lo + hi) >> 1;
        if (valid[tails[mid]].odo > v) hi = mid;
        else lo = mid + 1;
      }
      prev[i] = lo > 0 ? tails[lo - 1] : -1;
      if (lo === tails.length) tails.push(i);
      else tails[lo] = i;
    }

    // Восстанавливаем цепочку LIS от её последнего элемента.
    const keep = new Set<number>();
    let cur = tails.length > 0 ? tails[tails.length - 1] : -1;
    while (cur !== -1) {
      keep.add(valid[cur].idx);
      cur = prev[cur];
    }

    // Оставляем: точки LIS + все точки без валидного одометра (на своих местах).
    const result: TrackPointEntity[] = [];
    for (let i = 0; i < points.length; i++) {
      if (odoOf(points[i]) == null || keep.has(i)) result.push(points[i]);
    }
    return result;
  }

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

Физика в дополнении к порогам

Ещё одна выстраданная замена. Голый порог — скорость больше 200 км/ч между соседями — выброс слеп к размазанным прыжкам: если кадр перед скачком съел другой фильтр, средняя скорость падает ниже порога. Живой пример: 1,65 км за 35 секунд — «всего» 171 км/ч, порог молчит. Но оба края отрезка — стоянка, а из нуля в ноль за 35 секунд даже очень быстрая машина физически покрывает около 1,4 километра.

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

Стоянки — отдельная вселенная

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

Первое. Если в пакетах нет одометра — двигатель заглушен, а машина стоит там, где её заглушили. Координата стоянки физически детерминирована точкой глушения. До этого стояночную координату выбирало голосование кластеров по накопленному времени — пока однажды спуф‑кластер (~126 минут) не перевесил базу (~90 минут), и фильтр не переписал честную стоянку на ложную координату. Физический инвариант оказался надёжнее демократичного голосования.

Второе. Дрейф наматывает путь, если его считать по координатам, но машина никуда не уезжает. Отношение намотанного пути к смещению «от края до края» на реальных данных: дрейф — 1975 метров пути при смещении 192 (извилистость «дороги» десятикратная), реальный медленное движение по промзоне — 2953 при 1586 (≈ 1,9). Между ними пропасть, в которую и вбит порог. Приятный бонус: этой метрике не нужен ни CAN, ни LBS — чистая геометрия, работает на любом трекере.

Последний рубеж: интеграл

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

Выдаёт спуф интеграл. Суммарный GPS‑путь физически не может превышать рост одометра больше, чем на GPS‑шум. В том кейсе путь за окно составил 72 километра при росте одометра на 22 — превышение в 3,3 раза. Честный трек, включая извилистые дороги и дискретность одометра, держится ниже 1,6–1,8. Дальше техника: скользящее окно по росту одометра, порог входа в вырез и порог продолжения пониже — гистерезис, потому что хвосты спуф‑петель дают отношение на самой границе и без него выживают.

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

Не только резать

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

Решение пришло со стороны LBS: привязку к сотовой вышке глушением gps сигнала не сбить, трекер цепляется к физически близкой соте. Момент старта определяется по CAN‑скорости, место — по лучшей вышке до этого момента, а дорожный маршрут от места старта до первой честной GPS‑точки дорисовывает движок маршрутизации. Отдельный страж по одометру сначала доказывает, что начало действительно срезано, — иначе фильтр не вмешивается. Попутно пришлось научиться выбраковывать мусорную геолокацию самих вышек: сота физически не бывает дальше ~35 км, а базы иногда резолвят её за 800 — без отсечки стартовая точка улетала в чужой регион.

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

Так конвейер из карательного органа начал превращаться ещё и в восстановительный.

Что в итоге

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

 public async applyFilters(points: TrackPointEntity[], ...) {
  let result = points;
  const rawPoints = points; // сырьё пригодится для реконструкции

  // ── время и дубли ──
  result = this.deduplicateByTime(result);
  result = this.filterOdometerOutliersByMajority(result); // LIS против подмены времени
  /* … */

  // ── локальные фильтры: телепорты, заморозки, высота, скорость ──
  /* … ещё дюжина шагов, обменивающихся метаданными … */

  // ── стояночная группа ──
  /* … */

  // ── интегральные + реконструкция: работают по максимально чистому треку ──
  result = this.reconstructStartPoint(result, rawPoints);
  result = this.filterGpsPathOdometerMismatch(result, protocol);
  result = this.filterOrphanIslandsByOdometer(result, protocol);

  // fallback: вырезали всё — отдаём одну точку по лучшей вышке
  if (result.length === 0) return this.pickBestLbsFallback(rawPoints);
  return result;
}

Принципы, к которым всё свелось:

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

2. Иерархия арбитров: CAN (одометр, OBD‑скорость) → LBS → GPS. Чем ближе источник к физическим данным, тем выше доверие.

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

4. Судить сериями и интегралами, а не кадрами. Локальные метрики проигрывают самосогласованному спуфу — по паре соседних точек он неотличим от честной езды.

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

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

Если вы сталкивались с другими видами спуфинга или у вас есть интересные идеи / замечания — пишите в комментариях — с интересом прочитаю.