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

Мы смотрим на проблемы мониторинга под разными углами.
Лично я за свободу клиента в выборе системы мониторинга(по и железо), а Ваша позиция, видима следующие, предаставления клиенту смт которая будит работать на 100%, выполняя его задачи. Только не понятно, что делать клиенту, если задачь стало больше или они стали другими. Ваше решения и так работает на 100%...
А вобще тема следующая: ПО произведенное не вашей компании не детектирует привышение скорости по данным получиным на железе, произведенным не вашей компанией, но по данным, которое переслало это ПО на ваш сервер, почемуто детектируеться превышение?
Может за горой Вашего высокомерия я не заметил ответа...

Увважаемы разработчики из группы компаний "Техноком" , давайте перейдем к конкретной ситуации.

Объект М037КР
в системе Виалон (ID 157402132)  ретранслируется в agconv.tk-chel.ru:2453   
в протоколе EGTS  c  ID 1571000132
номер прибора отображаемый в  AutoGRAPH.Web =  9030187

Ниже привожу 

1. объедененный скрин данных  - отчет из AutoGRAPH.Web
2. на отчет нанесен скрин сообщений от объекта из Виалона, с тем же временным интервалом.
3. картинка создана для быстрого анализа ситуации ,чтобы меньше расписывать текстовой информации и обеспечить наглядность.

Как видим в отчете  из  AutoGRAPH.Web,   обнаружено  в периоде 02.10.2020  12:11:00 по 12:11:17  препышение скорости,  и отражено ее максимальное значение 153 км/ч.
Смотрим этот же временной интервал в Виалоне, максимальная скорость по сообщениям  была 62 км/ч, что для транспортного средства типа Мусоровоз КАМАЗ нормально.

Прошу представителя компании Техноком, посмотреть в транскодере или на сервере конвертации полученные в периоде 02.10.2020  12:11:00 по 12:11:17  координаты от указанного выше объекта,  и пояснить, откуда взялась  в  отчете из AutoGRAPH.Web   скорость  = 153 км/ч ????????????

Вопрос конкретный, прошу дать конкретный ответ. Заранее благодарен за помощь в решении проблемы.

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

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

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

Вам (конкретно Вам) нужно, чтобы имеющиеся на рынке железо и софт разных производителей были с примерно одинаковыми возможностями, чтобы это "давало свободу" и не мешало Вам относительно безболезненно переключаться с одного на другое.
Осталось еще, чтобы API у всех было одинаковым по функциям и их аргументам - а то придется переписывать у клиентов различные интеграции с 1С, SAP, различными CRM, SCADA и т.д. и т.п. - а это же "несвобода" и затраты.

Наша позиция, как и позиция любой нормальной рыночной компании на рынке: получение прибыли через максимальное удовлетворение имеющегося на рынке спроса + создание продуктов, которые могли бы вызвать спрос. Это банальная классика экономической теории.

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

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

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

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

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

Вы же выставляете универсальность как высшую ценность. Это напоминает мне небезызвестную страну со своей "демократией". Причем, Вы почему-то считаете, что и для клиента это несомненно высшая ценность, несмотря на очевидное противоречие с объективной реальностью. Спросите Александра Иванова из Вашего сообщества, например.

Не производите подмены понятий, пожалуйста.
Замена системы и обслуживание СУЩЕСТВУЮЩЕЙ СИСТЕМЫ - разные вещи.
Если я выиграл конкурс на обслуживание 1С у некоей компании, то это не значит, что по данному контракту можно ЗАМЕНИТЬ 1С на Excel или MS Access или "ПАРУС" и клиент обязан на это пойти.
Либо если Вы умеете обслуживать КАМАЗы, а клиент проводит конкурс на обслуживание тягачей MAN, то это не значит, что в случае выигрыша следует предлагать клиенту заменить MANы на КАМАЗы.

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

Если же клиент желает сменить ПО либо допускает его замену - это явно должно быть указано в условиях конкурса.
Это право клиента и никаких возражений у меня в данном вопросе не имеется.

Проблема в том, что в конкурсы лезут те, кто НЕ УМЕЕТ обслуживать ИМЕЮЩИЙСЯ объект обслуживания, указанный в условиях конкурса, а выиграв - требуют ЗАМЕНИТЬ объект обслуживания на тот, который они МОГУТ обслуживать.

TK-SK

Заявка №3885 , "Ретрансляция в систему АвтоГРАФ™ из внешних систем",  создана в вашем  хелпдеск: https://www.tk-nav.ru/tk-group/support

Ответ будет здесь опубликован , так как данная проблема существует при взаимодействии платформ Виалон и АвтоГРАФ™

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

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

Соотвественно расчетный параметр, это не реальное событие или параметр,  присланные  устройством, на расчеты могут повлиять факторы, которые программисты могли не учесть по какой то причине  при разработке алгоритма.

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

Приложите, пожалуйста, данные для анализа: данные от трекера и схему с настройками ПО.
Ваших слов и картинки совершенно недостаточно для понимания и разбора инцидента.

Уважаемый opl, прошу Вас - не искажайте мой вопрос.
Я его повторю: какое итоговое значение будет соответствовать числовому ряду скоростей в одной
временной точке (1 секунда): 42,54,18,40 или 38,51,19 ? Среднеарифметическое ? Первое значение за эту секунду ? Последнее значение за эту секунду ? Или какой-то иной алгоритм ? Насколько ему можно доверять ?

Поскольку именно ВЫ инициировали сравнение, то прошу выяснить это у Гуртам - иначе нам непонятно, на что ориентироваться.
Может там в таких случаях, когда приходит 5 разных значений за 1 секунду, берется случайное значение в диапазоне 10...65 км/ч. )))
Мы, разработчики, привыкли оперировать точными данными при анализе.
Если Вы утверждаете, что софт Гуртам дает некое верное значение из такого ряда сырых данных (в котором крайние значения отличаются аж в ТРИ раза: 18 и 54), мы бы хотели понимать: как, в таком случае, оно формируется. Представьте, что этот вопрос задал Вам Ваш достаточно грамотный клиент, увидев такие странные данные от Вашего трекера.

Ну хотите я сформирую Вам самые разные превышения в отчете Виалона ? Что это докажет ? Что Виалон криво написал свой софт или всё же не факт ?

Для анализа ситуации нам нужны данные и настройки из НАШЕГО софта по данному объекту за требуемый период. Полагаю, Ваш клиент может их запросить там, куда он предоставляет данные со своего объекта и откуда получает такие отчеты.
Без этого, проведение именно анализа, а не выдача кучи разных предположений - не представляется возможным, как Вы понимаете.

Еще раз обращаю Ваше внимание на то, что будь это ошибка программирования в софте, то такие проблемы были бы вообще со всеми трекерами, так как само ПО работает с данными только в формате АвтоГРАФ™ и ему без разницы, с какого трекера и чьего производства они были первоначально получены. Значение имеет только само содержимое "сырых" данных.

Дмитрий Л, Вы в очередной раз искажаете суть, уводя в сторону.
Я Вам повторю в 100500-й раз, читайте медленно и внимательно:
Если клиент желает сменить ПО либо допускает его замену - это явно должно быть указано в условиях конкурса. Это право клиента и никаких возражений у меня в данном вопросе не имеется.

Если же клиент объявляет конкурс НА ОБСЛУЖИВАНИЕ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ, НЕ ПЛАНИРУЯ И НЕ ДОПУСКАЯ ЕЁ ЗАМЕНУ, то принимать участие в конкурсе С УМЫСЛОМ потребовать замены в случае выигрыша - противоречит условиям конкурса, является недобросовестным и недопустимым.
(тем более, если данный умысел требует дополнительных затрат от клиента на приобретение новой системы или оборудования, не запланированных условиями конкурса)

Я достаточно понятно объяснил суть вопроса или требуются дополнительные разъяснения ?

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

Да все очень просто... после того как он выиграет конкурс на то что он не умеет делать, ты Константин, должен вылезать ему жопу, обучить его, и благословить его.

Считаю данный диалог бессмысленным.

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

К сожалению моя  учетная запись от ВАШЕГО софта  таких прав  не имеет. Подключу специалистов компании, у которой имеются соответствующие возможности.

Выяснили, уважаемый yavi  посмотрел в указанном периоде сырые данные пришедшие в виалон  и вот его комментарии:

"Я вижу в сообщениях от объекта (и на что указал tksk) что несколько сообщений в одной секунде.
По времени регистрации точно сказать невозможно, но т.к. оно +1 секунда от времени сообщения, есть вероятность что на самом деле там время сообщения было немного из будущего и зарегалось оно с временем сервера."

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