Математика расчета топлива в Wialon Pro

насколько понял проблема в тождестве формулы.

Данное тождество встречается исключительно редко, оно справедливо если есть идеальные данные по ДУТ, а это встречается крайне редко, в остальных случаях оно не гарантируется (подумаем над внесением в документацию этого момента с топливом)

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

+ в первом случае отчет всего за 4 дня а во втором за целый месяц, очевидно что за месяц разница вырастет больше

кстати а о каком ласт апдейте идет речь, с какой версии на какую?

Скиньте в личку сообщения и настройки. Заведу их на хостинг и сравню результаты с PRO.

P.S. разработчики PRO клянуться что изменения в алгоритмы не вносили.

Reference: VDI-78358-717
Reference: GZA-71988-828

Нет цены их клятвам)

В первоначальной реализации(PRO 1006) второй вариант рассчитывался как:
Уровень в начале интервала - Уровень в конце интервала + Сумма заправок
Но этот вариант был переделан по просьбе клиентов, поскольку имел ряд несовпадений с остальными рассчитываемыми данными отчета.
Причем эти несовпадения проявлялись на хороших и отличных графиках.

Минусы текущей реализации в том, что при среднего качества графиках(перепады данных в 10%-20% даже при фильтрации 10), суммирование заправок с разницей уровня не даст точных данных.
Что собственно наблюдается в Вашем случае.

Вы можете сделать запрос на возвращение старого метода PRO в качестве опции, но рекомендую попытаться улучшить показания ДУТ.
____________________________________________________________________________________________________________
Вы можете сделать запрос на возвращение старого метода PRO в качестве опции, но рекомендую попытаться улучшить показания ДУТ.
Еще раз для меня. Причем тут ДУТ? данные к вам заходят (вернее на Про) и А минус Б =С не получается.

Пишу здесь потому что не получаем в течении месяца вменяемого ответа.
Спасибо. Надеюсь на понимание.

Added after    9 minuts  18 seconds:
LeXXaT
Как хотите как нет. Но вы сами себе огромный минус сделали.
Приходим на тендер. Разрабы ПО, интеграторы и мы с нашим (вашим) Wialon.
Ставим, распаковываем, укатываем клиента. Отзывов куча. Все гуд.
А вот просто в отчете смотрят потрачено, заправлено и остаток. Ну не сходиться.
А я об стенку буду биться , вся команда селзов кружить но не сможет объяснить что за чудо алгоритм.

Зачем придумывать  и изобретать велосипед? Ведь ранее расчет работал.

LeXXaT, будем отстаивать  до конца?) ок.
Тогда по порядку еще раз:

1.babay
Вы недавно обновились с 1006 на 1301?
Мы очень давно обновляемся и обновились поэтапно и надеюсь что будем обновляться.
Опять же не корректно с вашей стороны говорить что вы там что то поменяли.
А как поменяли в тихую? без опроса, без предложений, без оповещения в блоге? Где это написано что бы можно было предъявлять нам.
Мол сами виноваты что не читали и тем более не знали.  Не хороший подход.

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

Каких клиентов? Которые взяли хостинг  подключили 2 машины к штатному датчику и спамили в  ТП? Что у кого дергается и падает уровень- Валидация вот ваша таблетка

Дальше.

Вот тут чуть не упал в когнитивный диссонанс

Поэтому расчет становился все сложнее и параметризированней - заправки вычисляются алгоритмом оптимизированным под эту задачу, расход своим алгоритмом.
А как это? Вот ту самый веский показатель и прям в глаз.

Пример сдачи топлива в полях заказчику. С контрольными замерами в сертифицированные мерники и сравнением в ПО.

Сливаем и заправляем топливо и разница в 0.5 литра до 2.1 что меньше 1-2%.
Мистика скажете Вы не может этого быть. Конечно не может. Годы работы и упорного труда.
Так что получается вообще не понятная ситуация. Даные ближе к идеалу а вот вас они не устраивают. Да и погрешность  вы почему то обещаете 15%)

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


Не работает.

А по поводу лодки

В конечном счете мы все в одной лодке, давайте решать проблемы обоюдно - вы предоставляете качественные данные, а мы предоставляем качественную аналитику

Предоставьте эту аналитику. И скажите нам чем вам помочь что бы она работала как заявлено.

Если стоит опция Расчет заправок без учета фильтрации, то уровень до и после заправки будет выводится по исходным данным, а при расчете Потрачено по ДУТ при опции фильтрации для уровня топлива учитывается фильтрация, и уровни соответственно будут отличаться (уровень исходного топлива, и уровень отфильтрованных значений), чем больше фильтрация, тем соответственно разница будет больше

В этом случае может лучше поможет датчик угла наклона, по которому можно будет валидировать ненужные скачи топлива

chdi В этом случае может лучше поможет датчик угла наклона, по которому можно будет валидировать ненужные скачи топлива

Не поможет! Что за теоретические гадания?
Вы хоть раз видели его в глаза. Да и вопрос не в скачках, не в красоте датчика. А что бы в статистике данные сходились.
Пусть они кривые с разбежностью и т.д. вообще бред, кардиограмма. Но начало и конец, потрачено в результате суммировались и уходили в 0-ль. Скажем так.

Added after    3 minuts  44 seconds:
DmitriyChЯ не могу полностью убрать фильтрацию для ДУТ, так как изза условий эксплуатации ТС начнут появляться ложные заправки и сливы.
Уберите, все равно не поможет. Я бы тут не подымал вопрос если бы в тикетах пол года не "разводили воду".
Да и понимаю манера высказывания) "агрессивная" . Но и как клиента меня должны понять. Я своим не могу вразумительного ответа дать  и услышать от разработчика что мы занимаемся, мы делаем. Мы смотрим.
Нет ответа. Только датчики угла наклона) может быть помогут. Такие ответы взрывают 2 кабинета оваций от сотрудников и пол часа на перекуре разговоров.

Надеюсь на понимание.

Добавим для статистики от себя...
Берём спец технику - экскаватор Tarsus 888.
Бак очень специфический, техника постоянно перемещается.
1. Без фильтрации, "Потрачено по ДУТ 522 л", математически столбиком получается 526 (70нач - 59кон + 515запр)
2. С фильтром "2", "Потрачено по ДУТ 512 л", математически столбиком получается 513 (70нач - 57кон + 500запр)
3. С фильтром "5", всё сходиться литр в литр.
Период использовался с 1.08 по 29.08

[center]Без фильтрации[/center]

Дополнение. Проверил ещё на 5 машинах, погрешность в среднем 0,5% (интервал месяц, машины дальнобой, баки по 500-900л., фильтр 3). Получалось чем больше значение фильтра, тем меньше погрешность.

Хочется все-таки услышать ответ от Gurtam, когда все-таки сделают правильный расчет топлива учитывая фильтрацию ДУТ? Понизить фильтрацию не могу, так как появятся лишние заправки/сливы. Расчет заправок без учета фильтрации убрать также нельзя, так как тогда не верно будут рассчитываться заправки. Вариант только убрать фильтрацию и повысить уровни определения заправок/сливов до 30 литров, но тогда система не зафиксирует реальный слив.

По сути вариантов решения просто нету без вмешательства Gurtam

Penzyak ура 1.5. литра всего за один день) а сделайте  отчет 30 календарных дней  ( отчетный период для бухгалтерии )
и посмотрите результат ( заправок по  больше и не дай бог сливы)

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

П.С. Ну 1.5 литра  на обьеме 40-29( нижняя граница на графике) всего то..... умножим на х10 ( 400литров бак).
Результат будет соответствующий.

Я так понимаю, уже не только наша компания начала обращать внимание на данную проблему. Плюс к тому, проблема имеет место не только на Pro но и на Hosting. А представители Gurtam все молчат... Затишье перед бурей?:)

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

Мы не можем так сделать, количество клиентов не позволит этого)) Да и зачем им графики, в основном, клиенту не нужен график вообще, ему нужно зайти в мониторинг по ссылке, нажать на кнопку для выполнения отчета и получить КОРРЕКТНЫЕ данные, ВСЕ!

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

Cranz, я прям сразу начал радоваться работает ( ну почти сразу..) . Но чет моя черствая душа не поверила. И не зря:

1. Обьект Мерс 465. Сделал отчет за месяц. Расхождение 16 литров. Думаю, ок за месяц. Норм цифра.
А по факту он то ездил 8ем дней всего. На 8ем дней многовато со средним расходом  в 44 литра при баке 260 литров максимум.
Видать это 5ти тонник,даже если допустить что с рефом он +1...2 литра в час. все равно он столько не есть. в 1.5- 2 раза меньше..

Но посмотрев настройках что за дут- а это кан. Махнул рукой. Это не принципиальный вопрос.
Да и добавлю скринов измените таррировку, у вас некрасивые пики на графике и соответственно расход не правдивый.
Скриный прикладываю, надеюсь обратите внимание.

Техника не работает 21 день. А 9ть и расхождение в подсчете 16 литров. Всего)Хотя не должно быть в принципе.

Пики на графике

И места тарировки, куда надо обратить внимание.

Cranz.А по теме. за 8ем дней 16 литров это нормально?

16 литров на почти 4 тонны, это 0.42%

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

Менее 0.5% это нормально, хочется конечно простого математического нуля, но когда используются сложные алгоритмы расчёта, то это не реально.

Проблема имеет место не с отдельными объектами, а в целом в методике расчета, если нужно, могу дать доступ на все объекты на нашем сервере с установленным датчиками уровня топлива, но от этого "потерянные" литры не появятся.

Говорили наверное про одно и тоже, но разными словами.
Сам решил посмотреть как у нас дела обстоят. В общем, среднеарифметическое 0.2-0.6% погрешность в формуле:
Было топлива + залито - потрачено = осталось.
Вроде как бы и немного, но когда идет битва за снижение на каждые десятые процента погрешности, то много.
Опять же непонятно как появляется эта погрешность и увеличивает ли она общую погрешность учета расхода топлива.
Я нисколько не программист поэтому не понимаю сути проблемы. Но то, что ТП отсылает в сторону установки датчиков уклона это явно некомпетентно. Тут же чистая математика.
Итого: есть погрешность 0.2-0.6%. Ситуация некритичная (по сравнению с теми кто пишет что у них 15% погрешность), но непонятная.

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

апдейт: 83 литров погрешность, или 1.3%
Бочка стоит на месте, уровень не колеблется.

Cranz) не помогает)

Added after     38 seconds:

Это погрешность не датчика уровня, не инструмента измерения а самого алгоритма подсчета. где все должно сводиться к 0лю.

Блин, ну мне то это можно не объяснять Я понимаю о чем речь идет.

osok так есть проблема ....
Сроки можно озвучить?
Диагностируем до.....
Решим до.....
От надежного и честного партнера хотим услышать сроки. Что бы я мог ориентироваться на сдачу проекта. Выплаты ЗП по данному проекту и подсчитать недополученную прибыль из-за заморозки оборотных средств . И так месяц долбим тех., поддержку и получаем невнятные ответы и не видение проблемы. А в ответ у вас не  Unlim.
И данная ситуация вызывает негатив. И на руку конкурентам Wialon.

А в моточасах сколько литров показывает?

LeXXaT, так подскажите,  несовпадение расхода это баг или фича?
И как устраняется - всем подряд при выходе нового обновления или в порядке исключения особо настырным?

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

Так же на стадии рассмотрения находится задача унификации  алгоритмов расчета топлива PRO и Hosting. В случае принятия такой задачи в разработку мы предоставим информацию по срокам.

LeXXaT, спасибо, понятно.
Вопросик еще: а правда ли, что теперь сотрудников Gurtam, которые заходят в ветку "Предложения для Wialon Pro" бьют розгами, а тех, кто еще и отвечает - увольняют?

Это с намеком что нет развития PRO???

Ну что ж, оказывается вполне гуманно!

Ну что когда будут исправления в Wialon Hosting? Скажите сроки

У нас в две конторы зазалазиют два конкурента с "правильным" расчетом. Нам бы быстрее исправлениен

Кстати точно также не сходится "Потрачено по ДУТ" в статистике с суммой "Потрачено по ДУТ" в сводке (если сводка сделана по дням). ТП сказала что это влияют сливы на границах дня, но даже если поставить галку "Исключить сливы из расхода топлива" несходимость данных все равно есть. Ну например у нас у клиента за месяц разница в 30 литров с 2960 литров. "Залечить" клиента о том что это погрешность датчика и алгоритма уже не получается, цифры то уже не то что математически не верные а просто в одной таблице одни, в другой другие. Все наши объяснения клиенту как отмазки

DmitriyCh
Для хостинга не планируются никакие доработки до решения задачи по унификации алгоритмов расчета топлива с PRO. По срокам см. выше.
Готов уделить время для анализа вашей ситуации - возможно сведем расхождение к минимуму. Скиньте в личку название объекта.

DmitriyCh
Проверил - Потрачено в статистике полностью совпадает с Потрачено в сводке:

DmitriyCh, в этом тикете Диана ещё 4 дня назад дала вам исчерпывающий ответ примерно на А4 печатного текста, после которого вы никаких новых вопросов по этому тикету не присылали.
В итоге не ясно, поняли ли вы её ответ, устроил ли он вас, ну и, важнее всего, разобрались ли вы как решать такую ситуацию с клиентами в дальнейшем.

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

Aliaksandr Kuushynau
Будем ждать решения данной проблемы на хостинге, очень хочется знать примерные сроки.

Aliaksandr Kuushynau
Как я могу помочь Вам в выявлении проблемы? У нас клиенты накаляются конкретно, абонентку по части ТС перестали платить, новые не ставят хотя потенциал есть. У нас соответственно убытки немалые

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

Aliaksandr Kuushynau
Скажите как Вам помочь в выявление проблемы? Приложим все усилия, проблема стоит остро

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

LeXXaTDmitriyCh, у нас сообщество не могу оставаться в стороне. Попробую объяснить проблему Дмитрия.
Аналогична нашей . Что бы средний расчет топлива брался не по графику и умному алгоритму а упрощенный.
От начала, конец , поделено на расстояние.

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

В любом случае есть Hosting/Pro SDK - где можно реализовать любую логику расчета.
На этом я предлагаю остановить затянувшееся обсуждение до выхода информации по срокам.

babay
Полностью согласен, спасибо что поддерживаете. Вот и у нас почти все клиенты не греют голову, так как не замечают математические нисхождения. А попалась парочку клиентов, у которых это сильно выражено в следствии спец настроек заправок\сливов, которые так же не убрать. Вот как раз для таких отдельных случаев и надо сделать доп настройку. Мне всегда нравился виалон именно изза богатых настроек топливных алгоритмов и надо довести эти настройки до идеала. Хочет заказчик чтобы математически сходилось - пусть получит! Как-то так...

Gurtam  на этом может еще и заработать, например, что бы дать доступ к каким то сложным функциям Wialon, надо пройти обязательное обучение. Таким образом левые пользователи так же отсеются и снизится негатив на Wialon.
p.s.
Это можно сравнить с фотошопом или Corel, если сделает профессионал, все скажут УУУХХХ, как класно, а если ничего не понимающий, то все скажут фотошоп и Corel - это гавно.

Natsu
Спасибо что пишите об этом. Надо вместе добиваться исправлений, а их все нет

Natsu
У нас разница и поболее была...