Ретрансляция в систему АвтоГРАФ™

Итак, Коллега...

1. Получается, что Ваш (используемый Вами в т.ч. для ретрансляции) софт всё же корректирует (!!!) "исходные сырые" данные, которые получает от терминала и записывает их как "данные, полученные от терминала". Корректирует такие фундаментальные и критические параметры, как время записи координатной точки трека (да и не только точек трека). Это очень-очень-очень плохо (и даже недопустимо). Т.е. фактически, не остается возможности установить первоначальную картину, что было реально прислано терминалом... Таким образом, нельзя быть уверенным ни в одной записи, которые Ваш софт записал в журнал как "запись, поступившую от терминала".

2. Получается, что и при ретрансляции, наш софт получает не реальные данные от терминала и его навигационного приемника, а обработанные, скорректированные и искаженные Вашим софтом данные и в которых время части координатных точек трека и других событий - ИЗМЕНЕНО на время приема этих точек сервером.

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

Теперь становится понятно, как получилось, что длина части отрезков трека на чудовищные значения не соответствует известнейшей по физике формуле Расстояние (длина отрезка трека) = Средняя скорость на отрезке трека * Время за которое этот отрезок был пройден объектом, когда время берется как дельта времени концов отрезка трека...

Также становится понятно, почему в нашем ПО возникла точка конца отрезка трека на 2.5 минуты смещенная относительно того, что Вы показали в софте Автоскана - потому что она пришла (при ретрансляции) в наш софт не "как есть" со временем от терминала (от навигационного приемника), а уже СМЕЩЕННАЯ Вашим софтом в точку времени приема данных сервером да еще и совместно с кучей других точек...

Будь это время смещено на единую величину для всех точек, а не спрессовано в точку, всё было бы не так математически и алгоритмически печально, так как хотя бы сохранилась бы дельта времени между этим точками и формула S=Vср.•t для отдельных отрезков трека работала бы как положено.
А сейчас они оказались спрессованы в 1 момент времени.
Т.е. объект, с точки зрения классической теории движения, якобы прошел аж несколько отрезков с конечной скоростью за бесконечно малое время (за нулевое время). Ну или, математически, скорость менялась несколько раз МГНОВЕННО, что подразумевает автоматически бесконечно большие ускорения в этой точке (первая производная от скорости). А значит, что Ваш софт и здесь использует некие искусственные костыли для срезки таких казусов, которые сам же и создал своими корректировками того, что корректировать нельзя...
Получается наплевать на "скорость-время-расстояние" и что объект теперь проходит 300 метров за 1 секунду со скоростью, внезапно, 40 км/ч... Мда... Или что объект за 1 секунду меняет курс по 4 раза и там должны возникать огромные угловые ускорения, а не только огромные продольные ускорения из-за столь же короткого времени изменения скорости объекта...

В общем получается ситуация, когда "тут пишем, тут не пишем, тут вообще рыбу заворачиваем, зато картинка красивая, а правда - ну кому нужна правда, ага...".

Ну и то, что после таких корректировок уже не восстановить, что приходило на самом деле - тоже... хм.... мда...

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

С уважением.

Уважаемый opl.

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

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

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

С уважением.

Хреновый (простите за мой русский) из Вас переводчик. Я достаточно понятно и не двусмысленно написал, что при поиске контрагента путем проведения торгов или запроса предложений ТЗ пишут не по одной шпаргалке, и те самые контрагенты руководствуются тем, что написано, а не тем, что Вы сейчас пытаетесь приписывать мне. К тому же, есть ряд предприятий, свободных от обязательств проведения обязательных конкурсов, и процесс выбора контрагента более предметный, с позиции того, что нужно заказчику и за что он готов платить.

Неуместные порции сарказма. К чему? Обслуживание - это действия, направленные на предоставление каких-либо услуг и/или на поддержание работоспособности оборудования, программного обеспечения (из словаря, если что). Вы как не обзывайте свои продукты, как не считайте это чем-то целым и не делимым, но все равно это является комплексом из оборудования и программного обеспечения (даже на офсайте Техноком отдельно представлены абонентское оборудование и ПО). Замена этого комплекса - это одно, изменение - это другое. Если первое - это полная замена оборудования и используемого ПО, то второе - это замена каких-то компонентов - оборудования или ПО. Это открытие для Вас, Константин? На примере того же Wialon (если на Вас как красная тряпка служит упоминание Технокома в подобном), недовольный качеством обслуживания клиент имеет желание поменять контрагента. Кандидат в исполнители при обследовании имеющегося на балансе Заказчика оборудования выясняет, что какое-то оборудование не выполняет заявленных функций, какое-то вполне работоспособно. При этом, например, Заказчик ранее пользовался мониторингом на базе Wialon Pro, а новый (предполагаемый) исполнитель использует Wialon Hosting. Если обе стороны пришли к соглашению с учетом необходимого изменения того комплекса, которым ранее пользовался Заказчик, то что помешает Закзачику получать желаемые им услуги спутникового мониторинга? Что в этом случае, замена или изменение?

Снова? А когда и чем раньше? Что не так с определением слова "Интеграция"? Или Вы все про "замену"? Выше я привел пример "изменений" при смене Исполнителя. Из примера произошла замена части оборудования и замена программного обеспечения, используемого для получения услуг спутникового мониторинга. Где и что не так с применением слова "интеграция"? Или все, что не АВТОГРАФ - это уже не интеграция? )
"О чем тут вообще говорить"? Если читать невнимательно или пытаться спорить с позиции "я всегда прав по умолчанию", то действительно не о чем.

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

Вы сами же указываете что эти данные не корректны, давайте их фильтровать, удалять и т.д, ЗАЧЕМ эту " крайне сомнительную ценность" обрабатывать при формировании отчета по скорости, понимая что получится ошибка?? Давайте попытаемся устранить коллизию.

TK-SK, если у вас  не используется  параметр speed,  котрый передают 90% терминалов, а делается  математический расчет, я вас прошу   рассмотреть возможность  доработки  алгоритмов и исключить  попадание в отчет по скорости не корректных данных  при обработке    последовательности координат с одинаковым timestamp.

autokirov@gmail.com

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

В виалоне сообщения  с одинаковым timestamp  создают проблемы с выводом в отчет не верной скорости?? НЕТ

В АвтоГРАФе  сообщения  с одинаковым timestamp  создают проблемы ?? ДА. 
Это влияет на чтото?  - ДА, не верный расчет скорости оъекта в отчете
Полученные ошибочные результаты расчета скорости в отчетах, по событиям  с одинаковым timestamp,  можно считать верными? -НЕТ

А теперь autokirov@gmail.com  ответьте мне, если вам пришел штраф 50 тыс руб за превышение скорости на 500 км/ч, сформированный на основе не верных математических расчетеов, вы готовы его оплачивать??

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

В этом случае не меняется время и не сливается по 10 точек в 1. У нас на вход системы пришли данные, где точки пачками по 3...10 слиты в точки с одинаковым временем. Причем там приличные куски трека...
К тому же время там - время принятия СЕРВЕРОМ, т.е. когда принято - а это вообще время никак не связанное с самим объектом.
А если там бы временно передача отпала ? А потом 500 точек попали бы в односекундную пачку по времени их приема ?! Причем эта пачка отстояла бы от последней точки до неё на кучу минут или даже часов ? Крайне сомнительная "корректировка".

А здесь не совсем "фильтрация" в классическом смысле. Фильтрация в СМТ- это когда берутся исходные данные, записанные в БД или файлы иного формата "как есть", а потом система выдает конечный результат с этой самой фильтрацией по внутренним алгоритмам... когда исходные данные есть - потом можно фильтр менять (параметры), включать, отключать, чтобы глянуть в первозданном виде... а мы сейчас имеем, что входные данные пишутся не "как есть", а сразу корректируются/искажаются невосстановимым уже образом, т.е. все последующие обработки / фильтры / детекции накладываются уже на искаженный вариант, а не на исходный + еще и передаются в таком искаженном виде в другие системы.

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

Т.е. понять, где был объект реально в тот или иной момент времени - становится невозможно. А поскольку после такой процедуры остается неизвестным, какие именно точки писались "как есть", а какие "со временем приема сервером", то доверия нет ни к одной точке трека и ни к одному моменту записи сработки датчика, получается...

TK-SK  ну вот, хоть какой-то конструктивный диалог начал проявляться, благодарю.

Я понимаю что в ПО АвтоГРАФ должен иметься и уверен, что  имеется функционал, позволяющий исключить выдачу ошибочных расчетных данных в отчеты. Дело в том, что у меня нет возможности сконфигурировать правильно ТС в ПО АвтоГРАФ, нет таких прав в имеющейся учетной записи.

По этому в тикете я дал контакты специалистов, которые обслуживают и конфигурируют ТС и всю информацию по даному ТС для его идентификации.
Далее я уже пока ничего сделать не могу, пока вы или эти специалисты не посмотрят общие фильтры / параметры настроек

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

1) Механизм ретрансляции в Wialon -- это отправка сообщений из базы данных Wialon в сторонние платформы.
Разработан он для того, чтобы получая данные  в Wialon от разных приборов в разных протоколах была возможность отправить данные в каком-то конкретном протоколе на внешнюю платформу. Ретранслировать сырые данные, полученные в протоколе,  например, Teltonika или Galileosky по протоколу, например,  EGTS невозможно.

Для отправки сырых данных от прибора на разные платформы необходим не инструмент ретранслятора из Wialon, а инструмент проксирования данных. Например, flespi

2) Конкретно по протоколу EGTS скорость передается в пакете EGTS_SR_POS_DATA в параметре SPD и регистрируется в Wialon на основе этого параметра. Аналогичным образом скорость   ретранслируется из  Wialon.

3) Не существует 100% правильного алгоритма работы с сообщениями из будущего на стороне платформ. Ни фильтрация, ни ожидание наступления нужного времени в будущем, ни регистрация с текущим временем сервера не может являться 100% правильным, т.к. сама по себе ситуация с сообщениями из будущего не нормальная.
Единственно правильным решением данной проблемы является решение проблемы времени сообщения от прибора. Большинство терминалов позволяет синхронизировать время со спутниками GPS или операторами связи.

Благодарю Вас за исчерпывающие разъяснения.

opl мы уже сообщили организации, которая работает с этим клиентом об инциденте и предоставили ссылку на нашу переписку.

Данные с  неисправного прибора  в протоколе wialon ips ретранслируются на сервер-транскодер  технокома, откуда потом ретранслируются  в протоколе автограф конечнику? На основе этих данных, без всякой проверки, автоматизированная система высылает штрафы?