Чего мне не хватает в Wialon (CAN - и это все о нем)

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

Хорошая идея, было бы еще здорово чтобы Gurtam team, преобразовывал теги производителей в стандартные CAN, тогда и производителей просить ни о чем не надо.

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

В Wialon есть все инструменты, которые позволяют создать датчики и представить информацию в том виде, который удобен конкретному клиенту. Если возникает вопрос с поиском конкретного параметра -- вы всегда можете обратиться на hw@gurtam.com и мы постараемся решить вопрос.

Все верно. Можно все сделать ВРУЧНУЮ. Это трудоемко и требует большой квалификации интегратора.
Результат: один и тот же SPN для разных машин будет назван по-разному (по настроению интегратора). И "привязан" к разным датчикам.

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

Не нужно разбираться с сотнями параметров для каждого терминала, нужно один раз "закачать" базу данных стандартных SPN.

Цель: облегчить жизнь и интегратору и вашей техподдержке.

Не нужно "каждый датчик с каждым параметром производителя".

Нужно "каждый SPN привязать к одному датчику". Всего в стандарте около 3000, на практике - пару сотен хватит "за глаза". Каждый SPN нужно привязать только к одному "датчику".

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

Автомобильные протоколы стабильны десятилетиями, новые параметры только добавляются, старые не удаляются.. На практике нужны пару сотен параметров и они уже давно есть в стандарте.

Без обид: рекомендую прокачаться по CAN, недавно в Москве был семинар, просите Locme повторить его в Гуртаме.

Да, да... Особенно когда производитель позволяет ставить произвольные теги... Вы как себе представляете преобразование силами системы, которая ничего не знает о фактическом параметре, настроенном в приборе для этого тега?

1. Разунифицированы только заголовки, тэги. Я уже писал - тут Виалону придется разбирать каждый формат производителя. Только формат, не каждый тэг, поскольку тег так или иначе однозначно соответствует стандартному: адрес+номер SPN.  Далее идет HEX по стандарту.

2. Кто мешает уточнить WialonIPS в части тегов ? Задать правило, уверен, производители поддержат.

Еще раз - задача действительно трудоемкая, но стоит потраченных усилий, автомобили с CAN уже почти все. Трекеров с CAN все больше, все лидеры давно с CAN: Teltonika, Автограф, Bitrek, Навтелеком, BCE, Technoton.

Кроме того - поддержка CAN это прямой путь к автозаводам, сейчас они воспринимают Wialon как детский лепет, и справедливо. Поддержка CAN это - удаленная диагностика, чтение паспортов ЭБУ -  выход на сервис. Т.е. настоящий профессиональный уровень. Безусловно, Гуртам (или кто то другой) придет к этому. Перспектива за оборудованием и софтом, которое штатно ставится на конвейере и работает не только автопарк, но и на автопроизводителя.

О flespi это умеет, тогда задача еще проще, воспользоваться базой flespi.
Да различных устройств 750, но далеко не все они работают с CAN фильтруем оборудование и получаем 119 приборов.
https://gurtam.com/ru/gps-hardware/auto?caps%5B%5D=can

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

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

P.S

Еще раз ключевые моменты:

1) Трекеры НЕ шлют данные кан шины в сыром виде.  У каждого трекера свой формат данных. Раз пошли ссылки на семинар, то см. https://www.youtube.com/watch?v=rslfyZqx4ec  23.50  -- вопрос, пересылают ли терминалы данные с каншины по GPRS в сыром виде.
Аналогично почти все трекеры.
Данные в стандарте J1939 не попадают на платформу в  сыром виде. Невозможно написать универсальный парсер по стандарту J1939 и выдирать эти данные из разных трекеров.

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

2) Многие трекеры позволяют настраивать данные для выдачи.
Например, зарезервировано 20 параметров, и пользователь  в конфигураторе выбирает, что передавать в этом параметре.
Т.е.  клиент Иван Иванович, в io_145 передает уровень топлива, клиент Петр Петрович в параметре io_145 передает пробег одометра.
Платформа не может понять, какие именно пользовательские данные передаются трекером. Поэтому, при всем желании, создать универсальную таблицу для всех (и даже абсолютного большинства) клиентов невозможно.

Многие трекеры поддерживают протокол WialonIPS. Так почему бы не начать с этого ? Стандартизировать сообщения из CAN в протоколе.

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

vinkel Данные передает не протокол, а трекер, и упирается дело уж явно не в протокол  

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

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