Сглаживание ДУТ в Fort-Monitor
Много лет пользуемся Вашей системой и никак не можем победить проблему посуточного сглаживания ДУТ.
Т.е. когда отчет по топливу строиться за несколько дней, данные по ДУТ сглаживаются по каждым суткам отдельно и потом тупо "склеиваются", при этом на стыках 0:00 всегда возникают сливы если ТС ездит/работает ночью.
Бороться с этим приходилось путем снижения сглаживания в ПО Fort-Monitor до минимума (5-10), перенося всю работу по сглаживанию на алгоритмы трекера и ДУТ.
Сейчас возникла ситуация с ДУТами по CAN-шине, по сути штатными (кстати вместе с оборудованием FORT), когда мы не можем использовать сглаживание 10, т.к. есть небольшие характерные колебания штатного ДУТ определяемые как ложные слив-заправка. При увеличении сглаживания до 30-50 график CAN-ДУТа становить практически идеальным, но при работе машины ночью обязательно вылазит слив в 0:00 при склейке графиков.
Клиенты часто замечают данный слив раньше нас, т.к. сложно уследить поедет машина работать ночью или нет.
Объяснить такое поведение графика сложно.
Имеем 10 опыт работы с разными системами мониторинга, к сожалению такой "нюанс" нигде больше не встречается, специально проверяли.
Всегда слив в 0:00, причем чем больше стоит сглаживание в настройках датчика, тем "красивее" график уровня топлива, но больше слив!
Если сглаживание 30, слив ~20л.
Если сглаживание 50, слив ~30л.
Сглаживание работает по количеству точек, но при построении отчета за 2 суток, как мы выяснили, каждые сутки рассматриваются алгоритмом отдельно и на границах суток алгоритм не смотрит в соседние сутки.
Т.е. для примера точка по ДУТ 1 минута, сглаживание 60.
Например в 23:30 алгоритм смотрит на 30 точек назад суток и 30 точек вперед суток и считает среднее.
Далее в 23:45 алгоритм смотрит 30 точек назад и только 15 точек вперед и считает искаженное среднее (завышенное).
Далее в 23:59 алгоритм смотрит 30 точек назад и только 0-1 вперед (т.к. сутки кончились) и считает еще более завышенное среднее, т.к. не учитывает снижающиеся значения если машина едет.
Далее алгоритм переходит к новым суткам и в 0:00 алгоритм смотрит 0 точек назад и 30 точек вперед и считает сильно заниженное среднее, т.к. не учитывает более высокие значения с прошлых суток.
А потом происходит "склейка" гарфиков по суткам и в 0:00 обязательно слив.
Слив есть всегда когда машина работала в полночь, на графике всегда ступенька, далее зависит только настроек минимального слива - попадет слив в отчет или нет.
Увеличение сглаживания не при каком раскладе не должно приводить к ложным сливам. Это полностью дискредитирует систему в глазах клиента. После этого любой реальный слив может преподносится как некорректные настройки системы и так до бесконечности.
-
Сейчас запускаем этот объект на Виалон, будем делать сравнение алгоритмов обработки данных по топливу с CAN-шины.
Важно отметить что это оборудование FORT, неужели "стороннее" ПО справится с обработкой данных лучше чем "родное"???
Результатами сравнения обязательно поделимся.
-
Вот, общее обсуждение алгоритмов работы сервера форт монитор, которые производитель ПО не обсуждает даже в тикетах.
Для справки, так поступает не только алгоритм по топливу, но и вообще любые алгоритмы, обрабатывающие всё в фотре.
Приборы их тут не причём, это уже на Фортовой Эре-Глонасс выяснили, которая не передаёт данные без активного зажигания.
П.С. Команда Форт монитор - мы тут новый СТАРЫЙ баг по контролю геозон Вам можем подвезти, на оборудовании,
которое 100% ОНЛАЙН без потери спутников работает 24/7. Вот прям та же ситуация, что и с топливом у автора.
П.С. Опять будете ссылаться на СВОЁ видение работы системы, которую вы продаёте и поддерживаете? Или всё же прислушаетесь к реальным пользователям и будете обсуждать "косяки" и пути их исправления?!!
П.C.С. Д. Э. Кнут Искусство программирования, том 3. Сортировка и поиск IBSN 5-8459-0082-4 ...
Войдите в службу, чтобы оставить комментарий.
Комментарии
Комментариев: 2