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

Поэтому попробуем провести исследование на обезличенных данных с реальных транспортных средств южной инфраструктурной геозоны платформы управления автопарками Waliot. Юг выбран по нескольким причинам: во-первых, это самый крупный кластер Waliot по количеству собственных объектов мониторинга и соответственно телеметрии, во-вторых, здесь мы сможем оценить влияние РЭБ и дорог с серьезным перепадом высот (перевалы и серпантины).

Для того, чтобы оценить погрешность пробега по одометру и ГНСС, нам потребуется телеметрия с автомобилей, которые передают эти данные в СМТ. Пробег по спутникам можно рассчитать на основе данных от навигационного оборудования. А вот со значением одометра сложнее, так как получение данных штатного одометра автомобиля требует обращения к бортовой электронике автомобиля. 

Пробег по спутникам

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

• Микроконтроллер с программой управления (прошивкой). Этот компонент отвечает за управление всеми остальными компонентами устройства и обеспечивает корректную работу оборудования.

• GSM‑модуль со встроенной или выносной антенной. Практически все современные трекеры используют общедоступную сотовую связь (GPRS, 3G, LTE) для передачи данных по сети Интернет до телематического сервера. Поэтому транспортную телематику можно отнести к категории автомобильного Интернета вещей (Automotive IoT).

• GPS‑модуль со встроенной или выносной антенной (‑ами). Качественные современные модули работают сразу с несколькими спутниковыми системами, такими как, американская GPS, российская ГЛОНАСС, европейская Galileo и китайская Beidou. Это позволяет использовать данные из разных навигационных систем, чтобы улучшить итоговый результат определения местоположения.

• «Черный ящик» — внутренняя память как временный буфер для хранения телеметрии до успешной отправки данных на телематический сервер. Чаще всего это обычная FLASH память, распаянная прямо на плате, или слот под MicroSD карту. Буфер накапливает телеметрию, пока нет сотовой связи, и как только объект попадает в зону действия сети мобильного оператора — данные отправляются в систему мониторинга.

• Внешние интерфейсы для подключения дополнительных датчиков. Помимо сбора GPS-данных автомобильные трекеры также рассчитаны на сбор показаний со всевозможной периферии: датчики уровня топлива (ДУТ), температурные датчики, датчики угла наклона и многое другое.

Получается, что от автомобильного трекера по сети Интернет мы получаем телематические пакеты на сервер СМТ с GPS-данными (текущие координаты, скорость и направление движения, и техническая информация об условиях решения навигационной задачи) и опционально с показаниями дополнительных датчиков (напряжение на аналоговых входах, значение цифровых выходов, температурные показания и прочее), к которым как раз относится и CAN-шина. 

Дополнительно хочется отметить, что оборудование от различных производителей работает по собственным коммуникационным протоколам. Чаще всего это бинарный протокол с передачей данных по TCP/IP. Есть и универсальные протоколы, например, протокол межсерверного взаимодействия EGTS (ГОСТ 33472-2015), который поддерживается большинством современных навигационных устройств сертифицированных для использования в России.

Радиоэлектронная борьба и глушение спутниковых сигналов

Радиоэлектронная борьба (РЭБ) и глушение сигналов навигационных спутников играют значительную роль в определении точности пробега, фиксируемого с помощью GPS/ГЛОНАСС, и могут существенно влиять на работу систем мониторинга транспорта.

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

• Создание помех навигационным сигналам: установка глушащих устройств или объектов, затрудняющих получение сигнала.

• Искажение навигационных данных: создание ложных координат, ведущих к дезориентации, что также называют спуфингом.

• Создание зон с отсутствием сигнала: блокировка передачи сигнала GPS/ГЛОНАСС, создающая “провалы” в навигационных данных.

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

В условиях многолучевости и при искажении сигнала возможно получение неправильных координат, из-за чего маршрут, пройденный автомобилем, может выглядеть на карте ломаным или срезанным (“размотка” и “полеты”), что приведет к завышению или занижению пробега. Например, сейчас в транспортном мониторинге остро стоит проблема спуфинга с подменой реальных координат на искусственные круговые траектории.

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

Пробег по одометру

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

1. Через OBD-II разъем. OBD-II (On-Board Diagnostics) — это стандартный диагностический разъем, которым оснащены практически все современные автомобили. С помощью OBD-II можно считывать множество параметров автомобиля, включая пробег, если этот параметр доступен через диагностическую систему. Подключается специальный телематический модуль, поддерживающий OBD-II, и через стандартные протоколы (например, ISO9141 и KWP2000) происходит запрос на получение данных одометра. Такие данные могут быть считаны в режиме реального времени и переданы на телематический сервер.

2. Через CAN-шину. CAN (Controller Area Network) — это внутренняя сеть автомобиля, через которую передаются данные от различных датчиков и систем, включая одометр. Телематический модуль подключается к CAN-шине и считывает сообщения, которые передают показания одометра. Обычно такие устройства должны быть запрограммированы для конкретных моделей автомобилей, чтобы корректно интерпретировать данные.

3. Через штатные телематические системы. Многие современные автомобили оснащены телематическими системами, такими как OnStar, Ford Sync или Mercedes Me, которые собирают данные о пробеге и других параметрах автомобиля. Телематические системы собирают данные напрямую из бортовой электроники автомобиля и передают их в облачные сервисы производителя. Некоторые системы позволяют интегрироваться с внешними приложениями через API, что может дать доступ к данным пробега.

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

Подготовка тестового набора данных

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

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

Проанализируем всю телеметрию за 2024 год в базе данных Waliot на территории ЮФО. Посчитаем для каждого объекта мониторинга количество телематических записей всего и со значением пробега по одометру, а также посчитаем какой процент телематических записей трекера содержит показания одометра по CAN. Выполним соответствующий запрос на аналитической реплике основной базы данных и сохраним результат в файл CSV (идентификаторы и другие чувствительные данные заменены):

После выполнения запроса получаем файл can_mileage_counters_2024.csv на более чем 20 тысяч строк. Это объекты мониторинга, которые присылали хотя бы раз телеметрию в 2024 году.

Посчитаем сколько трекеров прислали показания одометра по CAN-шине, хотя бы 1 раз:

Всего 669 трекеров. Это к слову о том, что подключение к CAN-шине сложный процесс и остается на усмотрение каждого Клиента как опциональной услуги по мониторингу транспорта. Но для анализа следует взять объекты, которые шлют показания одометра достаточно часто. Посмотрим на распределение объектов по частоте отправки данных с одометра к общему числу их телеметрии:

Отсюда можно сделать вывод, что если инженеры настраивают подключение к CAN-шине, то оно работает без проблем в большинстве случаев. А ТС, которые шлют одометр в телеметрии через раз, направлены в нашу техподдержку на проверку ;) Мы для своих целей возьмем объекты, которые присылают одометр более чем в 95% своих пакетов:

Теперь оценим общее количество записей для каждого из объектов в нашей итоговой выборке:

На гистограмме видно, что бОльшая часть трекеров прислала менее 1 миллиона пакетов за 2024 год. Есть странный выброс за пределами 3.5 миллионов, который скорее всего указывает на нестандартную конфигурацию трекера или проблему с оборудованием - информация будет также передана техническому отделу. 

Само собой при расчете отклонений пробегов мы будем рассчитывать среднюю ошибку по объектам, чтобы объект с бОльшим числом точек не вносил бОльший вклад в статистику по сравнению с более "экономными" по телеметрии трекерам. Но для чистоты эксперимента все же исключим объекты, которые шлют более 1.000.000 пакетов за год:

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

Для выгрузки такого объема телеметрии напишем bash-скрипт, который выполним прямо на аналитической реплики в отдельной сессии терминала через утилиту screen:

Получаем итоговый файл can_mileage_telemetries_2024.csv на 194882659 строк и размером 16 Гб. Так как CSV это текстовый файл, он хорошо поддается сжатию. Используем gzip со стандартной степенью сжатия и получаем на выходе файл уже размером 3.8 Гб, который приятнее передавать по сети:

Разберемся с содержимым нашего датасета по столбцам CSV-файла:

• tracker_id - искусственный идентификатор трекера

• fix_time - время фиксации GPS данных в ISO 8601 формате

• latitude - широта WGS84 в десятичном формате

• longitude - долгота WGS84 в десятичном формате

• altitude - высота над уровнем моря в метрах

• speed - скорость движения в км/ч

• course - направление движения в градусах (азимут)

• valid - флаг валидности GPS-данных (определяется внутренними алгоритмами трекера)

• satellites_count - количество видимых спутников при решении навигационной задачи

• hdop - снижение точности в горизонтальной плоскости

• can_total_mileage - общий пробег по одометру с CAN-шины

Данные в транспортной телематике можно разделить на 3 основные категории:

1. Бизнес-данные, которые связаны с предметной областью и чаще всего являются частью первичного ключа и/или критерием для поиска.

2. GPS-данные (fix_time, latitude, longitude, altitude, speed, course, valid, satellites_count, hdop), которые формируются на основе показаний GPS-модуля в трекере.

3. Данные с дополнительных датчиков. В нашем случае это только показания одометра с CAN-шины автомобиля. Сюда будут относится все данные с переферии (внешние подключения).

Пройдемся по полям и проанализируем каждое из них. Поле tracker_id - это идентификатор устройства, телеметрию которого мы изучаем, - думаю, тут все понятно. Комбинация полей fix_time, latitude, longitude и altitude являются результатами работы GPS-модуля в навигационном устройстве. Важно понимать, что ГНСС никак не участвуют в расчете скорости и направления движения, все это выполняется на стороне GPS-трекера, поэтому speed и course - это расчетные значения на стороне оборудования. Количество видимых спутников (satellites_count) и HDOP - вспомогательная информация, которая позволяет оценить точность GPS-данных. Флаг valid - это результат оценки валидности GPS-данных на стороне самого трекера, значение этого флага определяется внутренним алгоритмом, и зачастую параметры этого алгоритма можно настроить. Ну и can_total_mileage - это фактическое значение одометра в автомобиле, полученное через CAN-шину.

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

Погрешность в поле tracker_id отсутствует, т.к. это идентификатор навигационного оборудования.

Поле fix_time - время фиксации GPS-данных. Точность времени в ГНСС это определяющий фактор точности, т.к. именно по дельте времени между отправкой и получением сигнала определяется расстояние от спутника до приемника. Все спутники оснащены атомным стандартом часов. Стабильность атомных часов порядка 10^-14, а значит погрешность в 1 секунду будет достигнута только спустя миллионы лет. Однако установка атомных часов в приемник пользователя невозможна из-за их невероятной дороговизны.

Поэтому в ГНСС-приемниках используется кварцевый генератор, стабильность которого составляет 10^-7, а погрешность 3-5 секунд в год. Чтобы это компенсировать в сервисных сообщениях спутниковых сигналов передаются параметры временнОго полинома, которые используются для привязки шкалы времени приемника к шкале спутниковой системы с точностью 20 нс (в приемниках геодезического класса).

В этой работе мы используем реальную телеметрию с автомобильных трекеров и никак не можем повлиять на погрешность GPS-приемников. Наша компания активно использует Навтелеком СМАРТ S-2433, с техническими характеристиками которого можно ознакомиться по ссылке: https://wiki.navtelecom.ru/ru/home/devices/characteristics/s243x. В этом трекере в качестве универсального модуля GNSS/GSM/Bluetooth используется SimCom SIM868E, очень популярное комбинированное решение, которое идеально подходит для навигационного устройства.

Поля latitude, longitude и altitude мы получаем как результат решения навигационной задачи на основе данных от видимых спутников GPS, ГЛОНАСС и Beidou. Погрешность этих данных мы можем оценить через количество видимых спутников и значение снижения точности в горизонтальной плоскости.

Точность высоты над уровнем моря обычно значительно ниже, чем у показаний широты и долготы. Только по паспорту в идеальных условиях мы получаем ±5 метров погрешности у altitude, в реальности высота по ГНСС имеет значительно больших разброс.

В следующей статье попробуем проанализировать показания высот над уровнем моря в нашем датасете и оценить влияние учета высоты в расчетах пробега в транспортной телематике. Stay tuned :)