1

Развитие систем мониторинга транспорта: видение Технотона

Тема: Развитие систем мониторинга транспорта: видение Технотона

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

Принцип 1
«На борту» нужно уходить от RS 232/485. В качестве интерфейса для интеграции датчиков уровня, расходомеров, устройств идентификации водителя, тахографа, видеокамеры и т.п. использовать CAN.  Со стандартным протоколом j1939 плюс фирменные сообщения (PGN) производителей допоборудования.
Что получаем?
а) Автоматом – работу со штатной CAN шиной. Автоматом – в смысле, что поддержка стандартного интерфейса и протокола позволит терминалу подключаться к машине,  если не нужны доп.датчики. А поставил датчик - информация от них органически вольется в поток данных штатного CAN. Сократится номенклатура терминалов и они станут проще.
б) Возможность собирать более качественные и более многочисленные данные, поскольку в нынешнем RS 485 с протоколом LLS (даже допиленном до уровня DUT-E Com) места уже нет.  А передавать можно много чего интересного, например для датчика уровня топлива: паспорт и коды самодиагностики датчика, информацию о времени и ФИО установщика,  уровень топлива в мм и дюймах, объем топлива в литрах и галлонах, тарировочную таблицу бака, время и объем заправки/слива, текущую погрешность измерения, настройки ДУТа (фильтрация, термокоррекция), температуру топлива, углы наклона бака по осям, напряжение бортсети, время подачи питания и время выключения датчика, время движения и время простоя машины. И это только от ДУТа.
в) Четко задокументированный протокол – меньше глюков и нестыков в прошивках датчиков и терминалов. Причем протокол тщательно продуманный.  Уйдем от произвола программистов, которые часто не очень понимают автомобиль и путаются в названиях параметров, единицах измерения и т.д.

На сегодня все, жду ваших соображений, критики, предложений. Спасибо!

2

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Есть желаемое, а есть действительность. На мой взгляд, тут дело не в конкретно CAN, а в стандартизации для всех производителей, чтобы не сложно было применить или заменить одно устройство другим в любой ситуации, и не париться по поводу, где у "этого" ДУТ на разъеме какие контакты, а где у "того". А в шину CAN производители авто лезть просто так не дадут. Тут с тахографами не всегда прокатывает, а если в CAN полезет многочисленная армия производителей автотрекеров, то...

ООО Инновационная компания "ДилЛайн"
www.dealline.ru
Дмитрий Ларионов
3

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Дмитрий Л пишет:

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

Полностью поддерживаю. Унификация трекеров, ДУТ, датчиков по разъемам, а также разработка и обязательная поддержка каких то общих стандартов протоколов передачи данных. Как, например, тот же OBD-II и CAN.
Думаю Gurtam пора продвигать идею, а начать с обязательной поддержки всеми трекерами протокола передачи Wialon IPS и универсального разъема.

navion.ru
wialon pro
4

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

.....ДУТы отомрут в среднесрочной перспективе (варварство это)....КАН шина однозначно.

5

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Все эти КЭНы-шмены, все это баловство.
Каждый производитель хочет создать, что-то своё и тянет одеяло на себя.
Терминалы не в состоянии поддержать кучу протоколов.
Вот нет, чтоб взять, пример с пром.автоматизации. У них там  MODBUS. Датчиков, каких хочешь, на все случаи жизни.
Интегратору есть из чего выбрать. Под любые задачи.
Почему бы не сделать , что-то такое же в терминалах мониторинга.
А то, у каждого свой протокол, причем самый крутой.
Производители терминалов сами же и тормозят прогресс в мониторинге.
Хотя попытка Технотона, сделать что-то похожее в мониторинге прослеживается. НО!
Опять же, Посмотрите на рынок автоматизации - того кол-ва датчиков, которое есть в пром.автоматизации, в мониторинге нет и скорее всего не будет.
Успехов в Ваших начинаниях.

6

Развитие систем мониторинга транспорта: видение Технотона

(24/09/2014 09:09:44 отредактировано SibNaviCom)

Re: Развитие систем мониторинга транспорта: видение Технотона

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

7

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

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

В точку, абсолютно согласен насчет унификации и разъема и протокола.

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

Более того, использование j1939 плавно выводит нас к простому, надежному и компактному протоколу передачи данных на сервер, где стандартная структура PGN используется как транспортный контейнер, а SPN занимает прикладной уровень и уровень представлений. То есть терминалу остается подхватить на шине PGN и перебросить его на сервер, вместе со своими данными, также упакованными в PGN.

По разъемам тоже есть хорошие кандидаты, чуть позже.

8

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

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

ООО Инновационная компания "ДилЛайн"
www.dealline.ru
Дмитрий Ларионов
9

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Эмиль пишет:
Дмитрий Л пишет:

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

Полностью поддерживаю. Унификация трекеров, ДУТ, датчиков по разъемам, а также разработка и обязательная поддержка каких то общих стандартов протоколов передачи данных. Как, например, тот же OBD-II и CAN.
Думаю Gurtam пора продвигать идею, а начать с обязательной поддержки всеми трекерами протокола передачи Wialon IPS и универсального разъема.

Wialon IPS - это фиксация текущего уровня систем. На перспективу вряд ли подходит. Не расписан уровень представлений (единицы измерения), идентификация параметров отдана на откуп производителю терминала и т.д. То есть не обеспечивается унификация и взаимозаменяемость терминалов.
Да и вообще, зачем изобретать велосипед? Есть тщательно продуманный и задокументированный j1939, в котором отлично прописаны транспорт, представления и прикладной уровень. На участке терминал-сервер нужно добавить только сеансовый и сетевой уровни. Вот здесь Gurtam и флаг в руки.

10

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

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

....по секрету....лезть не надо....данные снимаются бесконтактным способом....

11

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

qwerty16 пишет:

....по секрету....лезть не надо....данные снимаются бесконтактным способом....

Не всегда...

Eduard Vald / GoGPS Service
www.gogps.eu
Skype: tivald.ee
12

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

всегда

13

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

qwerty16 пишет:

всегда

Что используете для бесконтактного считывания? Крокодил Технотона, адаптер телтоники или что-то еще?

14

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Давайте распутаемся.

Вешать периферию СМТ (датчики и др.) на штатный CAN никто не предлагает.

Речь идет об отдельной цифровой шине, специально заточенной под мониторинг (телематическая шина). А сама телематическая шина строится на физическом CAN и на протоколе j1939.
То есть телематическая шина строится на отработанных в автопроме за последние 20 лет решениях штатной CAN шины.

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

Теперь к вопросу о количестве датчиков в СМТ.
Сегодня чаще всего это 1 ДУТ, иногда 2. Многие ставят расходомер топлива.
Редко кто ставит датчик нагрузки на оси. Пробивается информация о датчике температуры, устройстве идентификации водителя.
Все эти устройства имеют разные интерфейсы - начинается свистопляска с подбором терминала, конфигурированием входов терминала и плюс настройка датчиков в Виалоне.

Посчитаем на максимум, периферию СМТ, берем обобщенный автомобиль

Шасси, кабина, моторный отсек
1. ДУТ - 3 шт
2. Расходомер
3. Датчик нагрузки на оси -  2 шт
4. Устройство идентификации водителя (если нет тахографа)
5. Сборщик аналоговых сигналов (паук, который собирает обороты, температуры, дискретные сигналы) - на машинах, не имеющих CAN. Или шлюз - для машин, имеющих штатный CAN.
6. Дисплей водителя
7. Бортовой принтер
8. Сам онлайн терминал

Верхнее оборудование, прицеп
1. ДУТ
2. Расходомер
3. Сборщик
4. Дисплей водителя

В общем десятка 2 перифирийных устройств. На конкретной машине, конечно, будет меньше, но СМТ должна быть готова ко всем.

Решение:  весь зверинец периферии посадить на унифицированный интерфейс (CAN) и протокол (j1939). То есть терминалу достаточно иметь только CAN вход.

15

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

qwerty16 пишет:

всегда

Пока повезло значит smile

Eduard Vald / GoGPS Service
www.gogps.eu
Skype: tivald.ee
16

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

GoGPS пишет:
qwerty16 пишет:

всегда

Пока повезло значит smile


.....а как бесконтактно снимая данные  можно навредить?

...есть еще niCAN  кроме крокодила....

17

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

qwerty16 пишет:

....а как бесконтактно снимая данные  можно навредить?

Вы не поняли.
Я имел ввиду что не всегда есть возможность снять данные бесконтактным считывателем. В случае если в шину нужно отдать ACK, бесконтактно не получится...

Eduard Vald / GoGPS Service
www.gogps.eu
Skype: tivald.ee
18

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Соглашусь с автором - шина CAN идеальное решение. Хорошо подходит для условий любых условий работы ТС, облегчит добавление новых устройств любым производителем периферии (поскольку имеется хорошо документированный стандарт), позволяет организовать обмен данными в любую сторону (датчики - устройство, устройство - периферия), и в тоже время уменьшится количество проводов при установке множества устройств. MOD BUS  - более сложен на этапе настройки, и несколько ограничен в возможностях.

Хайруллин Шамиль
ООО "Смарт-сервис"
Самарская область
smrservice.ru
19

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Poddias пишет:

. MOD BUS  - более сложен на этапе настройки, и несколько ограничен в возможностях.

Зато не привязывает терминал к  датчикам и параметрам выдаваемым с этих датчиков.
Вы только вдумайтесь. Ведь по сути мы решаем те же задачи комплексной автоматизации, что и пром автоматизация.

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

В такой конфигурации получается следующее.

1) Производитель терминала, не привязывается к конкретным реализациям протоколов датчика(Омником, DUT_E_COM & etc). Его задача получить с шины по заданным пользователем адресам информацию и передать её на сервер.

2) Задача производителя датчиков - описать карту регистров с параметрами, которые может сгенерировать датчик.

3) Задача Wialon не меняется. :-)

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

20

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

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

Сергей Чубаров.
Директор ООО "Ратеос".
www.rateos.ru   rateos@rateos.ru
+7 (499) 731-4390, 731-9716
21

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Попутно развею заблуждение о несовместимости  протоколов DUT-E и Омникомм LLS - они совместимы. В DUT-E только добавлены коды самодиагностики и кое-что по мелочи.

ModBus - конечно, нечто цивилизованное, по сравнению с текущими протоколами омникоммовского корня.
Но - проехали. ModBus устарел и в промавтоматизации, а в автомобилях и не появлялся.

В чем преимущества CAN/j1939 по сравнению с ModBus ?
1. Проще в реализации, поскольку нижние слои протокола реализованы в стеке CAN.
2. Не нужен Мастер, то есть датчики не требуется прописывать в терминале и настраивать терминал на регистры. Плаг энд плей.
3. Главное - в ModBus не прописан уровень представлений (единицы измерения) и прикладной уровень. Грубо говоря: взял из регистра "уровень топлива" четыре байта, а что это: у.е., мм, дюймы, литры? Да и название регистра не факт, что совпадет с названием соответствующей структуры в терминале и на сервере. Сшивка - ручками программистов, отсюда ошибки, разное видение и т.д. В CAN/j1939 напортачить труднее,
сказано:
SPN 96
FUEL LEVEL
Data Length:    8 bits
Resolution:    0.4 %
Data Range:    0 % to 100 %
все - не забалуешь

Есть и проблема: нет полного перевода на русский. В общем, переводим силами Технотона толстенную книжку стандартов.

22

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

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

Хайруллин Шамиль
ООО "Смарт-сервис"
Самарская область
smrservice.ru
23

Развитие систем мониторинга транспорта: видение Технотона

(26/09/2014 23:02:37 отредактировано GoGPS)

Re: Развитие систем мониторинга транспорта: видение Технотона

kaplunski пишет:

Плаг энд плей

Иногда Плаг энд прэй...

Eduard Vald / GoGPS Service
www.gogps.eu
Skype: tivald.ee
24

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

Poddias пишет:

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

Если нужно подключиться и к штатному CAN и к телематическому CAN, то 1+1=2, терминал должен иметь 2 CAN входа, либо можно использовать шлюх шлюз для закачки данных (избранных) из штатного CAN в телематический CAN. Вот такой шлюз, к примеру.

Развитие систем мониторинга транспорта: видение Технотона

25

Развитие систем мониторинга транспорта: видение Технотона

Re: Развитие систем мониторинга транспорта: видение Технотона

kaplunski пишет:

В чем преимущества CAN/j1939 по сравнению с ModBus ?
1. Проще в реализации, поскольку нижние слои протокола реализованы в стеке CAN.
2. Не нужен Мастер, то есть датчики не требуется прописывать в терминале и настраивать терминал на регистры. Плаг энд плей.
3. Главное - в ModBus не прописан уровень представлений (единицы измерения) и прикладной уровень. Грубо говоря: взял из регистра "уровень топлива" четыре байта, а что это: у.е., мм, дюймы, литры? Да и название регистра не факт, что совпадет с названием соответствующей структуры в терминале и на сервере. Сшивка - ручками программистов, отсюда ошибки, разное видение и т.д. В CAN/j1939 напортачить труднее,

1. Модбас реализовать не сложнее. В CAN просто принять 8 байтное сообщение, более длиное сообщение по протоколу BAM- тяжелее.
2 Терминал - все равно остается мастером.Некоторые сообщения все равно будут по запросу. Иначе упремся в пропускную способность шины. В вашем протоколе тоже придётся прописывать маски PGN (аналог регистров в МОДБАС).
3. И не надо прописывать в траспортном протоколе уровень представления. Расшифровка проходит на сервере по алгоритму заданному пользователем и по документации производителя. Ни каких программистов не надо!

P/S я не против CANa/ Хоть он и удорожает и датчики и терминалы. У CANa тоже есть свои преимущества.
Например если происходить вмешательство в работу ДФМ, то ДФМ мог бы выслать мгновенный Флаг "Cheat". И терминал мог бы передать эту информации на сервер. Кстати, Александр Романович, у вас будет такая функция?