Чего мне не хватает в 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 или любая иная платформа).

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

Т.е. производители между собой не договорятся, слать данные в едином формате не будут, это все понимают, но Gurtam должен придумать протокол, в котором никто данные передавать не будет? Как-то так себе PR получится

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

Производители не договорятся между собой, но каждый по отдельности с Гуртам  - договорится. Все заинтересованы в полноценном сборе и обработке CAN данных.

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

Объекты: любой автомобиль или трактор. Параметры: коды неисправностей, паспорта. Это невозможно.

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

И данные от разных машин получаются несравнибельные : один и тот де параметр (SPN) каждый называет по разному и привязывает к разным "датчикам".

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

Если-бы у меня были подобные проекты, хотя-бы пара-тройка, однозначно пошел-бы по пути разработки собственного аппса, и разбору / агрегации пакетов специализированных контроллеров и датчиков через flespi, например.
Но не пытался-бы от Гуртам добиться того, на что система не рассчитана.

Но это сугубо мое видение, отстраненно-теоретическое. Я-ж не знаю ваших деталей.

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

Наметилось два пути
1. Для наиболее популярных протоколов трекеров - сделать в Виалоне разбор тэгов.
2. Всем остальным предложить поддержать некий универсальный протокол для CAN сообщений.

То, что мы называем тэгами на самом деле стандартная связка SA (адрес отправителя)+PGN (номер группы параметров). Далее по положению внутри PGN определяется SPN (номер параметра по стандарту). Все это описано в стандарте. Если вы посмотрите на сообщение Галилео в HEXе вы увидите в явном виде описанную выше стандартную структуру.
То есть, зная стандарт, можно автоматически разобрать информацию.

Согласен, это будет уже нестандартная информация.

Teltonika, Bitek, Galileosky.
И популярность я бы предложил смотреть не по количеству подключенных на Виалоне (много может быть подключено и простых китайцев без CAN), а по объему выпуска терминалов и "прокачанности" в CAN. То есть - на перспективу будущих подключений CAN терминалов.

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