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

Если вы столкнулись с проблемой некорректного определения пробега в отчете, на треке или в сообщениях, то в первую очередь проверьте, какой тип счетчика пробега выбран у вас на вкладке Основное в свойствах объекта:

• GPS
• GPS + датчик зажигания
• Датчик пробега
• Относительный одометр

Узнав, какой счетчик используется в вашем объекте, выберите соответствующий раздел статьи.

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

Выбросы координат могут появляться из-за плохой связи со спутниками Глобальной Навигационной Спутниковой Системы (ГНСС). Чтобы определить, что выбросы имели место, перейдите на вкладку Сообщения и выгрузите данные для нужного объекта за проблемный период. На карте вы увидите трек, по которому можно будет определить наличие выбросов: координаты сообщений значительно отстоят от фактического местоположения объекта.

В данном примере явным признаком проблем с определение местоположения объекта является параметр HDOP — он имеет значения >1.

Wialon имеет ограничение: не более 1 сообщения должно приходить от объекта за 1 секунду. Если терминал передает более 1 сообщения в 1 секунду, хронология сообщений может нарушиться и трек будет выглядеть аналогичным образом. Причина — некорректная расстановка сообщений с позиционными данными (координатами) в базе данных Wialon. В таких случаях, в настройках терминала следует снизить частоту отправки сообщений с данными.

Возможные варианты решения:

• Использовать Фильтрацию валидности сообщений;
• Изменить настройки Детектора поездок.

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

В некоторых случаях счетчик (вкладка Основное в свойствах объекта) работает на основе GPS-координат, но при этом также создан отдельный датчик пробега (вкладка Датчики в свойствах объекта). В отчетах, например, с таблицей Поездки колонка Пробег будет выводить значение по GPS (суммарное расстояние между координатами), но значение колонок Начальный/Конечный пробег будет рассчитано следующими методами:

• Если значение датчика пробега имеется в первом/последнем сообщении интервала, то система использует эти значения.

Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

1. 10 км
2. -- км
3. -- км
4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 15 км (как в сообщении).

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

1. -- км
2. -- км
3. -- км
4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Конечный пробег получим 15 км (как в сообщении).

И еще один пример, где значение датчика пробега доступно только в первом сообщении:

1. 10 км
2. -- км
3. -- км
4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении).

• Если в первом сообщении интервала нет значения датчика пробега, то система ищет первое доступное сообщение со значением датчика пробега на этом интервале, а потом из него вычитается пробег до начала поездки, рассчитанный по GPS-координатам.

Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

1. -- км
2. -- км
3. -- км
4. 15 км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 15 км - рассчитанное по GPS-координатам значение или 15 км - 2 км = 13 км, в колонке Конечный пробег получим 15 км (как в сообщении).

• Если в последнем сообщении интервала нет значения датчика пробега, то система ищет последнее доступное сообщение со значением пробега на этом интервале, а потом к нему прибавляется пробег до конца поездки, рассчитанный по GPS-координатам.

Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

1. 10 км
2. -- км
3. -- км
4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 10 км + рассчитанное по GPS-координатам значение или 10 км + 2 км = 12 км.

• Если в первом и последнем сообщении нет значения датчика пробега, то система ищет первое доступное значение датчика, а потом из него вычитает пробег рассчитанный по GPS-координатам, чтобы получить начальное значение, а, чтобы получить конечное значение, наоборот, прибавляет к значению датчика пробег, рассчитанный по GPS-координатам.

Пояснения

Условимся, что фактически объект проехал 2 км, а сообщения приходили в следующем порядке:

1. -- км
2. 10 км
3. 15 км
4. -- км

В колонке Пробег получим 2 км (суммарное расстояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км - рассчитанное по GPS-координатам значение до первого сообщения интервала, в колонке Конечный пробег получим 10 км + рассчитанное по GPS-координатам значение до последнего сообщения интервала.

В такой ситуации если из-за каких-то сбоев датчик пробега не работал и присылал 0 км, возможно возникновение отрицательных значений пробега:

В данном примере для объекта создан датчик пробега на основе параметра can_mileage, который отсутствует в сообщениях вплоть до 18.12.2019 16:38:54:

После 16:38 и далее параметр всегда имеет значение 0, а датчик, соответственно, — значение 0 км.

Возможные варианты решения:

• Удалить датчик пробега и полностью перейти на пробег по GPS-координатам;
• Устранить проблему на стороне оборудования или переключиться на параметр с корректными значениями.

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

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

В качестве счетчика пробега выбрана опция GPS + датчик зажигания. При построении трека (через вкладку Сообщения, Треки или Отчеты) пробег равен 0 км, при этом сам трек на карте виден:

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

В данном примере для объекта не создан датчик с типом Зажигание, поэтому система игнорирует все сообщения и выводит 0 км пробега:

Возможные варианты решения:

• Переключить счетчик пробега на GPS;
• Добавить корректно работающий датчик зажигания.

В примере выше объект не присылает параметр, на основе которого можно определить состояние зажигания, потому проблема решена переключением на тип счетчика GPS.

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

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

В примере суммарный пробег по счетчику пробега составляет 26943 км, а по датчику пробега — всего 7069 км.

Причина — сброс параметра датчика пробега.

В такой ситуации происходит сброс до 0 км и далее снова рост до 6452 км (в примере такие сбросы повторялись неоднократно).

Возможные варианты решения:

• Использовать Нижнюю границу в настройках датчика;
• Использовать Валидацию, если сброс происходит при определенных обстоятельствах и удается выявить зависимость с другими параметрами (датчиками).

В примере выше достаточно применить нижнюю границу (0.01), т. к. сброс происходит произвольно и нет зависимости от других датчиков.

Таким образом посредством нижней границы удалось исключить нулевые значения (сброс до 0 км) и избежать некорректного расчета пробега.

Терминалы могут присылать сообщения слишком часто. Wialon имеет ограничение: не более 1 сообщения должно приходить от объекта за 1 секунду. При получении данных с большей частотой их хронология может быть нарушена и меньшее значение пробега может попасть в базу после сообщения с бо́льшим значением, пример на картинке ниже:

В таких ситуациях происходит переполнение счетчика до максимально возможного значения — 2147483648.

Возможные варианты решения:

• Отключить опцию С переполнением в настройках датчика (если была активирована).

В примере выше опция С переполнением была включена. Отключив ее, мы получили более корректное значение пробега:

Сообщения могут приходить с одинаковой временной меткой, нарушая хронологию, например:

В целом, на картинке выше, пробег выглядит корректным — 25.01 км, в отличие от предыдущего примера, где ошибка была очевидна. Однако, если взять из сообщений начальное значение датчика пробега на интервале — 9917.81 км и конечное — 9942.44 км, вычесть разницу, то получим пробег — 24.63 км.

Разница составляет 0.38 км на относительно небольшом отрезке трека. Погрешность будет расти с увеличением объема данных (количеством поездок). Причина ошибки — это конечно же нарушение хронологии сообщений. Система ожидает, что значение датчика будут расти. В примере видим падение с 9931.03 км до 9930.85 км и последующий рост до 9931.29 км. Происходит повторный расчет пробега между сообщениями зо значением датчика 9930.85 км и 9931.29 км, т.е. добавляются лишние 0.44 км.

Возможные варианты решения:

• Переключить счетчик пробега на GPS;
• Устранить проблему на стороне оборудования;
• Переключить датчик пробега на тип Относительный одометр и применить валидацию.

В примере выше удалось получить более корректные значения пробега с помощью перевода датчика пробега на тип Относительный одометр с добавлением валидации. Датчика относительного одометра основан на параметре в виде выражения: mileage-#mileage. Валидатор основан на параметре в виде выражения: time-#time. Нижняя граница для валидатора — 0, a тип валидации — Проверка на неравенство нулю. Счетчик пробега во вкладке Основное переключен на — Относительный одометр.

После применения валидации, пробег составил — 24.65 км. Сообщения, в которых временная метка совпадает, исключаются из расчета.

При возникновении вопросов по конкретным практическим случаям вы можете обратиться в техподдержку через почту support@wialon.com. Обязательно указывайте в вашем письме краткое описание ситуации со скриншотами, точное имя объекта, имя шаблона отчета для проверки, минимальный интервал времени для проверки (например, не месяц, а одни сутки), а также прочие важные детали.