Расширить виды индикации событий по баку
 

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

Хм... я против!
Во первых норма расхода показатель условный.
Камаз 1 день двигается с прицепом
Второй день без прицепа.
Будет разница по расходу ?
Камаз 1 день везет 18 тонн
Второй день везет 22 тонны
Будет разница?
Каждый день норму будете редактировать ? на каждый рейс ?
Выход в рейс на неисправном тс проблеммы водителя, правильно сделали, что наказали!
Водитель транспортного средства обязан соблюдать ПДД (в котором описан список поломок при котором тс эксплуатировать запрещается) Также к каждому автомобилю имеется правила эксплуатации в которых так же описаны поломки с которыми эксплуатировать запрещается, также на каждом предприятии в общих положениях обычно есть пункты о том, что водитель несет ответственность за целостность тс и соблюдения правил эксплуатации в случае выявления нарушений обязан прекратить использование тс и поставить в известность механика.
То что на это забивают проблеммы тех кто забивает.
Дальше, ссливы с обратки не возможны без внесения изменений в тс. Соответственно проверяется элементарно по следам на гайках и т.п. Вопрос где СБ ? спит сб вместе с механиками!

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

csistra, очень грамотно написали.
Приведу еще один пример . На рейсах с одного уровня безал потребляет 110 л/100км а с нижнего горизонта у того же белаза выходит 180л /100км

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

Добавлено через 2 минуты
А эту плюшку всегда можно сделать настраиваемой, хочешь показывает, хочешь не показывает, кому как угодно

csistra, plex,
все равно средний получается более-менее нормальный и характерный для авто.
Давайте анализировать статистику, а не рейсы.

AlexDoc, да не получается разница в 2 раза почти. Слава богу это механики на том предприятии понимают. Можно настроить под один режим, тогда будут сливы в другом или настроить по максимому, тогда даем возможность для сливов.

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

Добавлено через 3 минуты
Потому, что как правило, как только видят надпись слив, то сразу водилу на костер (кол, дыбу и т.д., у всех по разному), а потом только выясняются такие моменты, мол он ехал за комбайном по полю со скоростью 5 км/ч, или бак пробило или еще какие то моменты в которых водитель не компетентен, а водила уже наказан и обижен на все и вся.

Я тоже так год назад рассуждал.
Сейчас же по факту:
1-Сливы разбирает диспетчер мониторинга дабы отсеить тех сливы. Дальше целый регламент кто чего должен искать и глядеть.
2-Анализ перерасхода и т.п. делается проще если нужно по среднему. Берется период календарный месяц. Берется расход, пробег, расход в движении, расход на холостом ходу, время раблоты на хол. ходу. Получается три цифры: общий расход на 100, расход в движении на 100, расход на хол ходу (на стоянке) в час.
Дальше смотрим:
1-На каждую технику в книжке написано сколько оно ест на хол ходу. Если там другое значение то вариантов два или техника сломана или воруют с обратки.
2-Расход в движении должен отображать книжечное усредненное значение на 100.
3-Общий расход на 100 дает понимание для сравнения как тс работает на фоне других.
Дальше:
берем кривое тс. проверяем на наличие мелких стоянок в рейске 2-5 минут.
Если они есть анализируем неделю. Как правило если сливают с обратки то останавливаются приблизительно в одном месте, т.к. тара заканчивается одинаково.
Если видим такие остановки. Координаты в навигатор. Навигатор вручаем сбшникам и вместе с биноклем отправляем их в атаку. Дальше их песня.
И т.д. и т.п.

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

Шо за бред. Какая разница слив проверять на перерасход или перерасход проверять на слив. Клиенту расскажите что КРАСНЕНЬКОЕ В ЗАКЛАДКЕ БАК это есть перерасход (и по логике программы вы его не обманите). Пусть клиент выявляет из-за чего произошел перерасход ( слив или работа).

С одной стороны, можно ввести еще 1 (или даже не 1) значок для отображения "слива" на основании данных по завышенному расходу, с другой - никто не должен никого наказывать чисто по событию - всегда должны смотреть и разбираться - что произошло.
А то какая-то абсурдная ситуация. Если сигналка в квартире сработала - не означает, что однозначно вор залез, может просто форточку закрыть забыли... Разбираться надо...

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

Они обычно потом начинают анализировать и позже наказывать - это клиенту с опытом приходит

Про форточку хорошее сравнение.

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

кстати да ...у клиентов, которые также тянут прицепы - такая же просьба была в этом году..помню

Ну и уберите - настройки никто не отменял.

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

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

Как замечательно то все в теории то.
Приезжайте в гости. Сядете рядом с моими диспетчерами и посмотрим как вы под 200 единиц которые в радиусе 300км мотаются будете узнавать когда он пустой, когда он с прицепом и прочее.
И как вы будете успевать выставлять нормы, делать суточные отчеты, анализировать сливы, делать проверку путевых листов.
Даже если потребуется 5 мин на 1 тс посчитаем (люблю считать) Получаем в день вы сделаете 84 тс.

Добавлено через 17 секунд
а остальные 116 кто то еще должен сделать.

сделайте два бака с разными настроЙками и увидите

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

Вот здесь вы не правы, на больших предприятиях уделяют внимания на каждую единицу больше чем на малых, потому что у них экономия, казалось бы в мелочном вопросе, может достигать очень больших цифр (в деньгах) за счет количества объектов. А для того, чтобы получить хороший экономический эффект не надо вешать на одного диспетчера 200 автомобилей, иначе он повесится. оптимальный вариант 50 - 70 единиц техники на одного диспетчера, тогда будут получаться полные и своевременные отчеты и анализы работы подвижного состава, а так же хорошая статистика из которой можно будет делать верные выводы о появлении возможных проблем и принимать верные решения по предупреждению и профилактики этих проблем. И событие типа "Перерасход" помогло бы сразу начинать с анализа и выявления причины появления этой проблемы а не с того, что начинают прессовать водителя.

а как его (перерасход) определить? на основании чего должно появиться это событие?

Имеенно что не делаете. а только наблюдаете.
Не важно 50 тс или 100 или 1000. механизм один и тот же. Менется загруженность

Добавлено через 1 минуту
Да люди хочють 1 кнопку "делайся" так не бывает.

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

Да,я много хочу: кнопку, по которой будет считаться новый расход по какому то событию, пускай диспетчер жмет или ПО само определяет. Если нет ДУТа, ВЗО, хочу менять ту норму, которая предлагается ввести во вкладке двигатель по норме,при этом не меняя предыдущие записи. А к примеру поменять только сегодняшнюю, когда он ехал с перегрузом. Хочу: загружать, менять, копировать настройки расхода по ситуации из своей базы. Не хочу: запоминать, где то записывать, хочу хранить в файле. Хочу: рейс что бы делился по событию, по параметру, по контрольной точке, да пофиг как, но при этом автоматом менял расход, едет туда полный одна норма, едет обратно пустой другая норма. Я думаю, что позже найдется событие или инструмент по которому будет ПО его менять автоматом, пока просто мысли.

Общими словами: для начала, в ПО нужно внести запись события от диспетчера , а потом это событие применять по назначению. Т.е нажал диспетчер кнопку, ПО сделало запись, с 30.11.2012 с 20.49 диспетчер Иванов сделал такое то событие. с такого то часа расход изменился на 2 литра на этом Грейдере из-за морозов к примеру. норма увеличилась, и уже те два литра не слив и перерасход, а измененная норма..... ну что то типа того

Добавлено через 3 минуты
я пытаюсь помыслить за потребителя, если плохо получается, могу помолчать :)

Давно все есть. Детектируйте перегруз и подавайте на вход терминала сигнал, что перегруз (хоть датчиком веса, хоть тумблером, хоть по аппаратной КТ). В ПО давно уже сделаны специальные пороги "при вкл. датчике х". Чего еще-то ?

про возможности ПО - я знаю, с датчиками веса и/или контролем прицепного, все естественно проще и прозрачнее, когда их нет - сложнее, а если бы было событие (сигнал) от диспетчера в ПО, было бы чуть легче

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

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

теория это хорошо, хотелки это отлично.
Попробуйте на практике сначала, тогда Ваше мнение изменится.
Вся разница, что вы ДИЛЛЕР! а я клиент. Вы продали железки настроили и только отвечаете на наши "тупые" вопросы. А я каждый день работаю с этим.
И этим все сказано.


Он не понимает, он на практике этого не видит и не знает.
На практике все совесем по другому.
Еще раз повторюсь, можно сделать супер программу, установить мега классное железо, но до тех пор пока административные механизмы не перенастроить, до тех пор пока не написаны приказы, не закреплены зоны ответственности, до тех пор пока нет постоянного потока информации, до тех пор пока не закольцованы процессы НИЧЕГО ВЫ НЕ ПОЛУЧИТЕ! ДАЖЕ ЕСЛИ И ПОЛЦЧИТЕ НИКОМУ ЭТО НЕ НАДО!

о да! сама программа конечно ничего не сделает. данные должен котто анализировать и какие то меры принимать. когда первый раз внедряли систему ставили на машины поэтапно и когда оглашали очередноц список на установку, у водителей вопрос был один: за что? сейчас уже на все ставим,что покупаем и с дутами. берешь смотришь средний расход при одинаковых условиях движения и сравниваешь, так например выявили нерабочие форсунки, заставили водителей спокойнее ездить (зависимость от стиля езды просматриваеся в нашем случае 2-4 литра плюстм на 100 было) но сама программа это не сделает, надо учить персонал

Здорово ! Иными словами диспетчер всегда имеет возможность прикрыть слив, поставив виртуальное событие. Просто великолепно.
Кроме того, работа программы и ее результаты будут напрямую зависеть от того, чего там навертит некий диспетчер... Причем постфактум. Причем, хоть каждый день меняй и "ахалай-махалай" что хочу - получай...

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

latypovar, а почему бы не сделать детекцию "груженого" рейса хотя бы банальным тумблером в кабине водителя ? Это намного более надежный способ, результат которого окажется в памяти терминала, будет передан на сервер и т.п. Будет кому нести ответственность за достоверность, можно будет разбивать на рейсы по показаниям такого тумблера и многое другое.

Не будет это работать уже пробовал что то подобное..

Почему не будет ? Работает. Но ответственность за фиксацию "груженого" рейса естественно ложится на водителя.
Это как наемные водители с личным транспортом. Включил прибор в прикуриватель (или через тумблер) в рабочее время, рейс засчитан, забыл- проблемы водителя (рейс не засчитан). В личное время тумблер отключается.
Все просто и понятно. Главное, не забыть.

человеческий фактор потому что. и степень ответственности

Так тут ВОДИТЕЛЬ заинтересован, чтобы ему зачли вообще рейс или/либо рейс "груженый". Разве не так ?

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

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

я так понимаю, что хотят, что бы в программе был реализован алгоритм расчета расхода топлива согласно«Нормы расхода топлив и смазочных материалов
на автомобильном транспорте»

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

Нет конечно. Расход по нормативам всегда был встроен в ПО.
Хотят, чтобы по сути диспетчер мог руками расставлять задним числом со скольки и до скольки какой расход по его личному мнению должен был быть.
Посекундное расписание расходов, иными словами.[/QUOTE]

насколько я видел в программе присутствует норматив л/100 км, который применяется далеко не для каждого а/м. (а как он разделяет зима лето?)но надо ли нагружать ее этими расчетами? все равно как минимум массу груза проставить надо, а как быть если а/м с прицепами разной массы работает. мы эти расчеты в екселе спокойно организовали, можно туда и пробег грузитьиз автографа, до этого не дошли купили 1с, теперь туда гризить будем.

Добавлено через 1 минуту
Хотят, чтобы по сути диспетчер мог руками расставлять задним числом со скольки и до скольки какой расход по его личному мнению должен был быть.
Посекундное расписание расходов, иными словами.[/QUOTE]

а для чего?

Там два поля: зима и лето.

Какие еще методики, кстати, применяются по-Вашему к перевозчикам ?
В нормативы ? Покажите мне узаконенные нормативы по массе.

Подскажите, пожалуйста, как программа узнает зима сейчас или лето?
Не нашел такой настройки.

Для грузовых бортовых автомобилей и автопоездов нормативное значение расхода топлив рассчитывается по формуле:

qн = 0,01·(Hsan·S + Hw·W)·(1+ 0,01·D), (3)
где qн
- нормативный расход топлива, л;

S
- пробег автомобиля или автопоезда, км;

Hw
- норма расхода топлив на транспортную работу, л/100 т-км;

D
- поправочный коэффициент к норме (суммарная относительная надбавка или снижение), %.

Hsan
- норма расхода топлив на пробег автомобиля или автопоезда в снаряженном состоянии без груза. Коэффициент Hsan определяется по формуле:


Hsan = Hs + Hg·Gпр, л/100 км, (3.1)
где Hs
- базовая норма расхода топлив на пробег автомобиля (тягача) в снаряженном состоянии, л/100 км (Hsan = Hs, л/100 км, для одиночного автомобиля, тягача);

Hg
- норма расхода топлив на дополнительную массу прицепа или полуприцепа, л/100 т-км;

Gnp
- собственная масса прицепа или полуприцепа, т;

W
- объем транспортной работы, т·км. Коэффициент W определяется по формуле:


W = Gгр·Sпр, (3.2)
где Gгр
- масса груза, т;

Sпр
- пробег с грузом, км.


Для грузовых бортовых автомобилей и автопоездов, выполняющих работу, учитываемую в т·км, норма расхода топлив увеличивается дополнительно к базовой норме (из расчета в литрах на каждую тонну груза на 100 км пробега) в зависимости от вида используемых топлив: для бензина - до 2 л; дизельного топлива - до 1,3 л; сжиженного нефтяного газа (СНГ) - до 2 64 л; сжатого природного газа (СПГ) - до 2 куб. м; на газодизельном автомобиле ориентировочно - до 1,2 куб. м сжатого природного газа и до 0,25 л дизельного топлива.

При работе грузовых бортовых автомобилей, тягачей с прицепами и седельных тягачей с полуприцепами, норма расхода топлив (л/100 км) на пробег автопоезда увеличивается дополнительно к базовой норме (из расчета в литрах на каждую тонну собственной массы прицепов и полуприцепов) в зависимости от вида топлив: бензина - до 2 л; дизельного топлива -до 1,3 л; сжиженного нефтяного газа - до 2,64 л; сжатого природного газа -до 2 куб. м; на газодизельном автомобиле ориентировочно до 1,2 куб. м -сжатого природного газа и до 0, 25 л - дизельного топлива.

http://www.infosait.ru/norma_doc/52/...dex.htm#i63784

Добавлено через 3 минуты
и насколько я понимаю если в настроиках изменить расход то он поменяется за весь период, а как быть если а/м роботал и в городе и за городом? (тоже разые нормы) два норматива (зима и лето) есть, а как программа понимает когда какой применять?

olegg72, верно. Я предполагал большую ересь.
Однако.
Чтобы система реально работала, получение всех параметров должно быть автоматизированным.
Соответственно:
1. Терминал должен знать - какой именно прицеп прицеплен к тягачу.
2. Терминал должен знать массу груза и её изменения по ходу маршрута.

П.1. решается метками-идентификаторами, хотя это не шибко тривиальная задача и далеко не все на это идут.
П.2. Намного сложнее, т.к. до сих пор нет ни одного способа нормального измерения массы груза в кузове и прицепе с погрешностью не плюс/минус 20...50%. Либо, уполномоченное лицо (водитель, экспедитор, отправитель, получатель) должен вводить в терминал (например, через дисплей связи с водителем) массу груза в точках загрузки, промежуточных выгрузок, конечной выгрузки.
Тогда система будет работать по нормативам.

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

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

Так я и хочу, чтобы человек это анализировал, просто я хочу, чтобы это называлось не слив а перерасход :mat:

atc52, я сказал, что согласен, чтобы такие "сливы" помечались немного другим значком, означающим, что "слив" был детектирован по расходу на 100 км, а не по времени.
Это может оказаться как "перерасход двигателем", так и "слив в движении" (например, через обратку), который "перерасходом" называть нельзя.
На стоянке на самом деле всё одинаково - можно зажать педаль газа и будет "перерасход двигателем", а не "слив".
В обоих случая правило названия события должно быть одинаковым.
Разница только в методе детекции: в превышении порога л/час или л/100км.

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

Добавлено через 6 минут
Я как начинатель этой темы заявляю, что не хочу рассчитывать по норме, я все сказал чего хочу, а эти разговоры по поводу норматива который рассчитывается по сложной формуле надо перенести в другую тему :neothodiotte:

Добавлено через 5 минут
детекция различия между сливом и перерасходом должна быть настраиваемая пользователем с возможностью назначить по л/час, л/100км и л/мч.
Допустим мы примерно знаем расход топлива техники, мы устанавливаем границу "Расход" - Это диапазон перерасхода - "Расход" +15% - Это слив.

Добавлено через 2 минуты
(о;"Расход") - нет события
("Расход";"Расход"+15%) - перерасход
("Расход"+15%; "Бесконечность") - слив

Вот так будет понятнее

Добавлено через 46 секунд
15% это условно

О ! Наконец-то всплыло совсем другое, нежели о чем говорилось вначале...
Теперь становится ясно, что хочется несколько порогов детекции...
Ну там,
• норма
• небольшой перерасход
• большой перерасход
• ни фига себе какой перерасход
• небольшой слив
• нормальный такой слив
• большой слив
• слил больше, чем в бак помещается...
Только многопороговость - это совсем другое.

Сейчас детектируется именно "слив", поэтому, когда задается порог "слива", он должен задаваться с учетом этих % на плюс/минус перерасход.

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

atc52, представим, что мы ввели двухпороговость. Что будет, когда водитель начнет сливать так, чтобы оказаться примерно на границе порогов ? А получится куча записей "туда-обратно": "слив-перерасход-слив-перерасход". Разбираться станет еще сложнее - поверьте. Надо будет думать, как объединять этиинтервалы и в какую сторону их относить...