Дополнительные свойства

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

1. Расчет уровня топлива по пробегу

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

Вычисление слива/заправки происходит методом сравнения разницы между начальным уровнем топлива (X) на последующем интервале движения и конечным уровнем топлива на предыдущем интервале движения (Y). Если (X—Y)>0, то была заправка, если <0, то был слив, если значения одинаковы, то ничего не происходило. Но так, как любой из ДУТов имеет свою степень погрешности, в Wialon есть настройки, которые помогают отличить реальный слив/заправку от
погрешности. Эти парметры можно найти в настройках ДУТ:

• минимальный уровень слива,
• минимальное время остановки для определения слива,
• и некоторые другие.

2. Расчета уровня топлива по времени

В этом алгоритме нет сравнения уровня топлива между поездками — сравнивается скорость убывания топлива по ДУТ с расходом, рассчитанным математически.

Пример

Автомобиль стоит 10 часов. Слив производился крайне маленькими дозами, но на протяжении всей стоянки. Всего слито 60 литров топлива. Определить, слив это или расход топлива, можно будет по состоянию датчика зажигания объекта.

Расчет уровня топлива по времени оптимально подходит для контроля топлива у объектов, длительное время работающих без движения (генератор, автокран и т. п).

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

Вы можете воспользоваться несколькими описанными ниже подходами.

Вариант 1

Создайте виртуальный датчик зажигания. В качестве его параметра мы рекомендуем использовать усредненную скорость: (speed+#speed)/const2.

Вариант 2

Даже если вы не устанавливали датчик зажигания в объект или не уверены, какое имя имеет параметр, отвечающий за зажигание, в параметрах прибора может быть какой-либо признак, соответствующий работе двигателя. Чтобы воспользоваться им, сравните два сообщения от объекта: одно — когда зажигание вероятнее всего выключено; второе — когда включено.

Пример

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

hdop=1, odo=0, adc2=2.0475, adc12=1037, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=43811, ta=1,
gsm_lvl=55, total_fuel=407154, can_fls=101, can_taho=4797, can_engine_hrs=230420, can_mileage=137603392, engine_temp=123,
srv_dist=0, j1939_air_temp=9072, J1708_eng_hrs=230420, J1708_fl_used=430282, J1708_fl_lvl=101, I/O=80/0

При движении со скоростью — примерно такой:

hdop=1, odo=847.358764648, adc2=2.3595, adc12=1117, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=60167, 
ta=1, gsm_lvl=71, total_fuel=407178, can_fls=101, can_taho=9940, can_engine_hrs=230447, can_mileage=137609550, 
engine_temp=124, srv_dist=0, j1939_air_temp=9353, J1708_eng_hrs=230447, J1708_fl_used=430307, J1708_fl_lvl=101, I/O=d1/0

Непосредственно перед началом движения, как правило, зажигание включается:

hdop=1, odo=0, adc2=1.4937, adc12=895, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=60268, ta=2, 
gsm_lvl=64, total_fuel=407166, can_fls=100, can_taho=996, can_engine_hrs=230439, can_mileage=137605711, engine_temp=120, 
srv_dist=0, j1939_air_temp=9369, J1708_eng_hrs=230439, J1708_fl_used=430295, J1708_fl_lvl=100, I/O=80/0

Отбрасываем заведомо неточные параметры: hdop (точность), adcN (закономерность трудно определить), odo (относительный одометр в метрах), mcc mnc cell_id и lac (блок LBS данных), gsm_lvl (уровень сигнала GSM) и так далее. Параметр J1708_eng_hrs для данного объекта выглядит наиболее вероятным, т.к. не изменяется во время стоянки ночью. Как правило, можно использовать также pwr_ext. Если зажигание цифровое, то изменения значений можно отследить в блоке I/O = (подробнее в разделе Параметры входов и выходов).

Вариант 3

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

Возможные причины:

• В некоторых случаях система может считать, что в течение интервала отсутствия сообщений от объекта зажигание было включено. Установите значение по умолчанию 0 секунд в опции Максимальный интервал между сообщениями на вкладке Дополнительно свойств объекта. Влияние данной опции на расчет топлива описано в документации.
• Может быть создано несколько датчиков полезной работы двигателя. Проверьте, какие значения они принимают. Проще всего оценить это, построив в отчете простой график с одной из кривых Расход по расчету.

Предположим, расход топлива в городском цикле равен 10 л/100 км, а в загородном — 7 л/100 км.

• Создадим датчик зажигания (как в примере выше) и установим расход на холостом ходу в размере 1 л/ч.
• Средняя скорость движения в городе — 36 км/ч, за городом — 80 км/ч.
• Расстояние в 100 км при движении со скоростью 36 км/ч объект проедет за 2.8 часа. 10 л/2.8 = 3.57. Вычислим значение повышающего коэффициента при движении в городе: 3.57 / 1 (х/х) = 3.57.
• В результате проведения аналогичного расчета для загородного режима получаем коэффициент равный 5.6.
• Создадим датчик полезной работы двигателя, принимая во внимание тот факт, что объект не может тратить топлива меньше, чем на холостом ходу, и что до начала движения он неподвижен. В качестве параметра используем среднюю скорость (speed+#speed)/const2 и заполняем таблицу расчета (вручную либо с помощью мастера таблицы расчета):

Обратите внимание, что последняя пара точек — то, как система рассчитывала ранее (для скорости выше 80 км/ч расход топлива считался постоянным). Вы можете не использовать данный метод и изменить набор точек. Также 3 в данном примере — это минимальная скорость из детектора поездок объекта, соответственно, в вашем объекте данный параметр может быть иным.

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

При математическом расчете расход топлива вычисляется отдельно для каждой пары сообщений.

Используется следующий алгоритм:

1. Определяется состояние датчиков работы двигателя (датчик зажигания и датчики абсолютных и относительных моточасов) в текущем сообщении.
2. Для работающих датчиков суммируются значения, указанные в их свойствах в поле Расход, литров в час.
3. Вычисляются значения датчиков полезной работы двигателя, привязанных к датчикам работы двигателя.
4. Полученные значения суммируются по формуле k1 + (k2 - 1) + (k3 - 1) + … + (kn – 1). Таким образом формируется коэффициент. Если сумма коэффициентов меньше нуля или невалидна, то общий коэффициент принимает значение 1.
5. Для определения текущего расхода топлива объектом значение из пункта 2 умножается на значение из пункта 4.
6. Время от предыдущего сообщения до текущего умножается на значение из пункта 5.
7. Расход для каждой пары сообщений за указанный интервал суммируется и таким образом определяется расход топлива по расчету.

Как правило, сезонный коэффициент предполагает повышенный расход. Например, зимой расход топлива на 30% выше, чем летом. Допустим, что зима в вашем климате – с 01 декабря по 01 марта.

1. Создайте датчик полезной работы двигателя с параметром time:d.
2. Найдите, какому номеру дня в году соответствуют ваши даты. Высокой точности не требуется: год может быть високосным, а сам сезон — длиннее или короче. Например, для указанного выше периода — это примерно 334 и 59.
3. Создайте таблицу расчета, как на скриншоте ниже.
   

time – параметр, который присутствует в любом сообщении от любого прибора, и система автоматически вычислит номер дня по нему. Таким образом, при наступлении сезона к расходу топлива автоматически будет добавлено 30%.

Этот способ выгрузки данных об активности водителя считается устаревшим. Рекомендуемый и поддерживаемый способ — выгрузка через flespi. См. инструкцию How to configure sending tachograph data to Wialon using flespi (англ.).

1. Необходим тахограф и трекер, который поддерживает выгрузку файлов DDD.

2. Создайте водителя в системе мониторинга. Значение поля Код свойств водителя должно соответствовать номеру его персональной карты.

3. Создайте датчик типа Назначение водителя и добавьте объект в список автоматического назначения водителя.

4. На вкладке Команды свойств объекта создайте команду для выгрузки файла DDD. В зависимости от типа устройства синтаксис команд может отличаться.

5. Для отправки команды загрузки файла DDD объект должен держать TCP соединение открытым (таймаут зависит от типа и настроек трекера).

6. После выгрузки файла DDD в сообщениях появится:

   • строка driver_card1_file=C_хх_1256.ddd, register_ddd=0 — выгрузка прошла успешно, однако файл не прикреплен к водителю (недостаточно прав на ресурс или водитель с таким кодом отсутствует);
   • или строка driver_card1_file=C_хх_1256.ddd, register_ddd=1 — выгрузка прошла успешно, файл прикреплен к определенному водителю.

   Синтаксис ответа зависит от типа оборудования. Некоторые устройства дополнительно присылают ответ через окно Переписка с водителем.

   Время, необходимое для выгрузки файла, зависит от трекера (выгрузка может занимать приблизительно от 5 до 30 минут).

7. Просмотреть загруженный файл и проверить работу водителя за предыдущий интервал можно в приложении Tacho View.

8. Файлы DDD с карты водителя хранятся в ресурсе. Срок хранения таких файлов не ограничен, они удаляются вместе с ресурсом.

LBS (location-based service) — это сервис, который определяет местоположение объекта по координатам базовых станций GSM.

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

Точность LBS, как правило, меньше: она зависит от местных радиоусловий, плотности сети базовых станций, конфигурации сот. Однако с помощью LBS проще поймать сигнал. Это повышает шанс получить позиционные данные в сообщении, когда GPS недоступен.

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

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

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

Список поддерживаемых устройств смотрите на нашем сайте в разделе Оборудование.

Причин может быть несколько.

• Ваш прибор технически не может передавать lbs данные.
• Некорректные настройки прибора. Для определения позиции по LBS необходимо, чтобы прибор передавал минимум 4 параметра: mcc, mnc, lac, cell ID. Проверьте настройки прибора и удостоверьтесь в том, что устройство передает данные параметры.
• В настройках объекта в Wialon не активирована Фильтрация валидности сообщений. В окне настроек объекта перейдите на вкладку Дополнительно, установите флаг Включить фильтрацию информации о положении устройства в сообщениях и активируйте опцию Разрешить позиционирование по сотовым станциям.

Когда объект мониторинга не отправляет данные о местоположении по спутникам, Wialon считывает идентификатор базовой станции и ищет координаты в своей базе данных.

В Wialon используется собственная база данных. Она обновляется по мере получения от объектов новых сообщений, в которых содержатся LBS-данные вместе с GPS-координатами. Перед внесением в базу данных новые точки проходят дополнительную проверку. В данный момент в базе насчитывается более 62 миллионов точек.

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

Чтобы увидеть последнее местоположение объекта, определенное по LBS, воспользуйтесь LBS-детектором.

Чтобы в Wialon сохранялись LBS-данные объекта, откройте вкладку Дополнительно его свойств, включите фильтрацию валидности сообщений и активируйте опцию Разрешить позиционирование по сотовым станциям. После этого LBS-координаты будут использоваться в отчетах и при отображении объекта на карте. Для уведомлений необходимо также активировать опцию Учитывать LBS-сообщения в их настройках.

LBS-координаты объекта сохраняются, только если в сообщении они определены позже GPS-координат.

Если местоположение объекта определено по LBS, это можно понять по его отображению на карте и по иконке , которая показывается напротив его имени в рабочей области на вкладке Мониторинг.

Отправьте запрос на hw@wialon.com с указанием типа устройства для рассмотрения вопроса.

Если для вашего типа устройства заявлена расширенная экспертиза, напишите на hw@wialon.com с указанием всех подробностей. Вы также можете обратиться за помощью в настройке остальных устройств.

Отправьте запрос на support@wialon.com с указанием значений параметров mcc, mnc, lac, cell_ID.

Проверьте, настроено ли для объекта использование LBS на вкладке Дополнительно его свойств, а в случае с уведомлениями — включена ли также опция Учитывать LBS-сообщения в их настройках. Если проблема по-прежнему не решена, напишите на support@wialon.com с указанием всех подробностей.

Возможные причины и их устранение:

1. Были выбросы данных.

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

С выбросами можно бороться следующими способами:

• На вкладке Дополнительно в свойствах объекта включите фильтрацию информации о положении объекта в сообщениях и задайте необходимые параметры. Они не затронут старые сообщения, но будут применяться к новым.
• Чтобы получить более корректные данные в отчетах по уже зафиксированным в базе сообщениям, попробуйте настроить иначе детектор поездок объекта. В частности, уменьшите максимальное расстояние между сообщениями и увеличьте минимальное количество спутников.

2. Неправильно настроен или некорректно работает датчик, выбранный для счетчика пробега.

• Проверьте настройки счетчика пробега на вкладке Основное.