Где взять описания CAN-протоколов для разных марок?..

Alexo · 14.01.2015, 08:19

Эмуляторы датчиков для VAG-группы оказались вообще универсальными. Главная сложность с эмуляторами - правильно представлять САМО физическое поведение эмулируемой системы, и затем его имитировать. Для примера - имитируем ДМРВ (ФОРД). Для этого:
1. Необходимо посылать в шину 2 сообщения со своими идентификаторами. Одно шлется только в ответ на соответствующий запрос ЭБУ (когда он придет), второе - периодически один раз в 32 мс.
2. Данные условно можно разделить так: служебные данные и непосредственно измеряемые данные. ЭБУ с некоторой периодичностью отправляет сообщение - запрос, в котором содержится, в частности, информация о режиме работы датчика ДМРВ (оказывается, у ФОРД их несколько и по команде от ЭБУ ДМРВ должен в них как бы "переключаться", а вот, отчего режимы зависят - до конца не ясно, - нужно углубленно изучить трейсы с реальной машины при реальной езде). Ну, и собственно, данные о расходе (это в периодическом сообщении от ДМРВ), в формате 4 байта (двойной точности) - в м.куб/сек.
Некоторые байты чисто булевы - ("есть связь - нет связи", результаты самодиагностики датчика "исправен-неисправен" и т.д.), некоторые (их 2 - по одному для каждого 8-мибайтного сообщения) - всегда имеют значение 0 - по-видимому, зарезервированы, а сейчас не используются.. и т.д.
Основная сложность в эмуляции - понять как переключаются режимы и от чего это зависит...
То есть в общем эмулятор готов, однако, к нему нужна программная надстройка имитирующая его поведение. В настоящий момент, при совместной работе готовых эмуляторов датчиков скорости, ХХ, газа, ДМРВ, машина "глохнет" через 20-25 сек работы, при этом диагностика передает, что причина - ДМРВ (неверный режим)..
Как-то так.
Остальные байты в этих двух

Cotm · 14.01.2015, 11:40

Цитата:

Сообщение от 4еснок

Мне вот до сих пор интересно узнать,на каких протоколах общаются М.С.6.2 на Стралисе и ЕДЦ7 на Евро-5.

99,9% это J1939, погугли.

smekalych · 14.01.2015, 12:09

Alexo, Тема конечно интересная, но :
К примеру по форду от марки к марке (а точнее идентификатора мотороного блока) есть отличие в запросе PID к примеру МАФ по заводскому протоколу и по ОБД. То есть по итогу получаем разные значения одного и того же параметра (так написали софт софтописатели форд

)

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

Тем не менее за поднятие темы спасибо!

Cotm · 14.01.2015, 12:16

Цитата:

Сообщение от smekalych

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

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

smekalych · 14.01.2015, 12:18

У переферии как раз CAN ID сообщений может существенно отличаться, особенно что касается работы систем комфорта, развлечений и т.д.

smekalych · 14.01.2015, 12:26

Приложу пожалуй несколько файликов по теме.
Правда вся инфа на английском, но для тех кто в теме это не проблема

punks · 15.01.2015, 13:43

Может де компилировать прошивку Модуля 2CAN для какой нибудь CAN сигнализации. К примеру Starline E90. И вообще сама платка с ARM процессором на борту интересный объект для исследования. Она переводит can запросы в обычные Rx Tx.

zamj · 15.01.2015, 15:36

Чем elm-327 в терминале не устраивает!И какая декомпилляция (это не ассемблер)! Суть протокола iso 15765 почитайте!

zamj · 15.01.2015, 15:56

Ну для начала так

Alexo · 20.01.2015, 12:55

Один из участников любезно предоставил протокол обмена так называемого замедлителя, который применяется в грузовых и автобусах для регулирования крутящего момента на колесах в зависимости от многих факторов. Если он разрешит, то я выложу и сам протокол в дальнейшем. А пока- для конкретного примера этого замедлителя (ZF, насколько я понимаю):
Допустим, нам необходимо насколько возможно протестить замедлитель, протокол обмена по КАН с которым у нас имеется. В протоколе вначале идет описание распиновки разъема замедлителя. Относительно CAN интересны пины 21-24 и 48-51. При этом, для анализатора (допустим, Marathon – стоимость которого на сайте производителя вместе с ПО около 6500 руб. всего-то) нужны пины 22 и 49 (или 23 и 50 – как они обозначены в описании, - «redundant» или «дополнительные», так как скорее всего к ним ничего не подключается и они нужны как раз для подключения подобного анализатору оборудования). Возможно, надо будет подключить и массовый провод (24 или 51) и установить терминатор (резистор на 120 Ом) между (21 или 48 и земля). Можно и «вычислить» шину CAN идущую от разъема этого замедлителя где-то в другом, доступном месте и там к ней подключиться зачистив каждый из двух проводов для подключения. А есть и КАН-крокодилы, которые позволяют подключаться к проводам без гальванического контакта.
Ну, допустим, подключились, и, запустив ПО CANwise на ноуте, выбираем скорость. Тут надо пояснить – имеющийся протокол не описывает скорость обмена, так как он представляет из себя только лишь часть большого описания, касающаяся только замедлителя (это видно из того, что написано, например, «page 19 from 54», то есть, это было описание не только одного конкретного замедлителя, но, возможно всей системы, в рамках которой он работает). Видимо, где-то в общих описаниях и было конкретное значение скоростей обмена. Ну, да не беда – стандартизированных скоростей всего-то с десяток, а с такими системами как двигатель, ходовая и проч. вообще скорее всего скорость 500 кбит/сек. Так что скорость, хоть она и не описана – не проблема. Хорошо, вычислили скорость – т.е., просто установили очередную стандартную из предлагаемого списка и запустили прогу «стартом». Как только со скоростью «угадаем» и связь установится, - сразу в поле Receive появится куча данных. Далее удобнее использовать режим проги Tracer, в котором сообщения не «бегут» а «стоят» на месте, а в них данные меняются.
Теперь непосредственно описание сообщений и данных – в принципе все понятно из описания – кто (какой прибор) и с какой периодичностью посылает данные (например, скорость замедлитель получает во 2-м и 3-м байте сообщения от системы круиз контроля, сам замедлитель шлет в 1-ых четырех битах 1-го байта одного из своих сообщений информацию о том включен он или отключен, если включен, то по какой причине (что инициировало его включение в работу – ABS, ASR, transmission control, acceleration pedal и т.д.).) Всего по этому протоколу обмена с десяток различных сообщений, в которых приводится и управляющая и диагностическая иформация.
Теперь, что можно сделать дополнительно, кроме непосредственно диагностики.
А можно очень просто «откинуть» «подозрительный» прибор, с которым происходит общение по КАН у замедлителя, и вместо него посылать свои данные с помощью той же проги CANwise. Тут, конечно, надо знать что посылать, но процентов 90 описано в самом протоколе, а можно снять логи с заведомо испраного и т.д. – поле деятельности необъятное.
Просто хотел сказать на этом примере для авто, оборудованных CAN – прибор за 100 баксов + протоколы обмена > любого самого крутого дилерского сканера

14.01.2015, 12:18	#95 (permalink)
smekalych Завсегдатай Регистрация: 24.10.2014 Сообщений: 433 Вы сказали Спасибо: 97 Поблагодарили 178 раз(а) в 122 сообщениях Сказал(а) Фууу!: 339 Сказали Фууу! 15 раз(а) в 14 сообщениях Откуда: Россия, Санкт-Петербург	У переферии как раз CAN ID сообщений может существенно отличаться, особенно что касается работы систем комфорта, развлечений и т.д. Последний раз редактировалось smekalych; 14.01.2015 в 12:33..

15.01.2015, 15:36	#98 (permalink)
zamj Абориген Регистрация: 05.10.2014 Сообщений: 3,377 Вы сказали Спасибо: 143 Поблагодарили 1,710 раз(а) в 589 сообщениях Сказал(а) Фууу!: 43 Сказали Фууу! 45 раз(а) в 43 сообщениях Откуда: красная гора Авто: chery bonus	Чем elm-327 в терминале не устраивает!И какая декомпилляция (это не ассемблер)! Суть протокола iso 15765 почитайте! Последний раз редактировалось zamj; 15.01.2015 в 15:38..

14.01.2015, 08:19	#91 (permalink)
Alexo Участник тусовки Регистрация: 05.01.2014 Сообщений: 111 Вы сказали Спасибо: 1 Поблагодарили 62 раз(а) в 20 сообщениях Сказал(а) Фууу!: 0 Сказали Фууу! 0 раз(а) в 0 сообщениях Откуда: Земля	Эмуляторы датчиков для VAG-группы оказались вообще универсальными. Главная сложность с эмуляторами - правильно представлять САМО физическое поведение эмулируемой системы, и затем его имитировать. Для примера - имитируем ДМРВ (ФОРД). Для этого: 1. Необходимо посылать в шину 2 сообщения со своими идентификаторами. Одно шлется только в ответ на соответствующий запрос ЭБУ (когда он придет), второе - периодически один раз в 32 мс. 2. Данные условно можно разделить так: служебные данные и непосредственно измеряемые данные. ЭБУ с некоторой периодичностью отправляет сообщение - запрос, в котором содержится, в частности, информация о режиме работы датчика ДМРВ (оказывается, у ФОРД их несколько и по команде от ЭБУ ДМРВ должен в них как бы "переключаться", а вот, отчего режимы зависят - до конца не ясно, - нужно углубленно изучить трейсы с реальной машины при реальной езде). Ну, и собственно, данные о расходе (это в периодическом сообщении от ДМРВ), в формате 4 байта (двойной точности) - в м.куб/сек. Некоторые байты чисто булевы - ("есть связь - нет связи", результаты самодиагностики датчика "исправен-неисправен" и т.д.), некоторые (их 2 - по одному для каждого 8-мибайтного сообщения) - всегда имеют значение 0 - по-видимому, зарезервированы, а сейчас не используются.. и т.д. Основная сложность в эмуляции - понять как переключаются режимы и от чего это зависит... То есть в общем эмулятор готов, однако, к нему нужна программная надстройка имитирующая его поведение. В настоящий момент, при совместной работе готовых эмуляторов датчиков скорости, ХХ, газа, ДМРВ, машина "глохнет" через 20-25 сек работы, при этом диагностика передает, что причина - ДМРВ (неверный режим).. Как-то так. Остальные байты в этих двух

14.01.2015, 12:09	#93 (permalink)
smekalych Завсегдатай Регистрация: 24.10.2014 Сообщений: 433 Вы сказали Спасибо: 97 Поблагодарили 178 раз(а) в 122 сообщениях Сказал(а) Фууу!: 339 Сказали Фууу! 15 раз(а) в 14 сообщениях Откуда: Россия, Санкт-Петербург	Alexo, Тема конечно интересная, но : К примеру по форду от марки к марке (а точнее идентификатора мотороного блока) есть отличие в запросе PID к примеру МАФ по заводскому протоколу и по ОБД. То есть по итогу получаем разные значения одного и того же параметра (так написали софт софтописатели форд ) Еще я так понимаю основная вкусность вашей идеи это интерепретация сообщений CAN шины... Я так понимаю нужна билблиотека CAN сообщений, а эти сообщения очень могут отличаться (и реально отличаются), особенно у переферийных блоков разных производителей Тем не менее за поднятие темы спасибо!

15.01.2015, 13:43	#97 (permalink)
punks Новичок Регистрация: 04.01.2014 Сообщений: 22 Вы сказали Спасибо: 2 Поблагодарили 7 раз(а) в 4 сообщениях Сказал(а) Фууу!: 0 Сказали Фууу! 0 раз(а) в 0 сообщениях Откуда: Барнаул Авто: Toyota	Может де компилировать прошивку Модуля 2CAN для какой нибудь CAN сигнализации. К примеру Starline E90. И вообще сама платка с ARM процессором на борту интересный объект для исследования. Она переводит can запросы в обычные Rx Tx.

20.01.2015, 12:55	#100 (permalink)
Alexo Участник тусовки Регистрация: 05.01.2014 Сообщений: 111 Вы сказали Спасибо: 1 Поблагодарили 62 раз(а) в 20 сообщениях Сказал(а) Фууу!: 0 Сказали Фууу! 0 раз(а) в 0 сообщениях Откуда: Земля	Один из участников любезно предоставил протокол обмена так называемого замедлителя, который применяется в грузовых и автобусах для регулирования крутящего момента на колесах в зависимости от многих факторов. Если он разрешит, то я выложу и сам протокол в дальнейшем. А пока- для конкретного примера этого замедлителя (ZF, насколько я понимаю): Допустим, нам необходимо насколько возможно протестить замедлитель, протокол обмена по КАН с которым у нас имеется. В протоколе вначале идет описание распиновки разъема замедлителя. Относительно CAN интересны пины 21-24 и 48-51. При этом, для анализатора (допустим, Marathon – стоимость которого на сайте производителя вместе с ПО около 6500 руб. всего-то) нужны пины 22 и 49 (или 23 и 50 – как они обозначены в описании, - «redundant» или «дополнительные», так как скорее всего к ним ничего не подключается и они нужны как раз для подключения подобного анализатору оборудования). Возможно, надо будет подключить и массовый провод (24 или 51) и установить терминатор (резистор на 120 Ом) между (21 или 48 и земля). Можно и «вычислить» шину CAN идущую от разъема этого замедлителя где-то в другом, доступном месте и там к ней подключиться зачистив каждый из двух проводов для подключения. А есть и КАН-крокодилы, которые позволяют подключаться к проводам без гальванического контакта. Ну, допустим, подключились, и, запустив ПО CANwise на ноуте, выбираем скорость. Тут надо пояснить – имеющийся протокол не описывает скорость обмена, так как он представляет из себя только лишь часть большого описания, касающаяся только замедлителя (это видно из того, что написано, например, «page 19 from 54», то есть, это было описание не только одного конкретного замедлителя, но, возможно всей системы, в рамках которой он работает). Видимо, где-то в общих описаниях и было конкретное значение скоростей обмена. Ну, да не беда – стандартизированных скоростей всего-то с десяток, а с такими системами как двигатель, ходовая и проч. вообще скорее всего скорость 500 кбит/сек. Так что скорость, хоть она и не описана – не проблема. Хорошо, вычислили скорость – т.е., просто установили очередную стандартную из предлагаемого списка и запустили прогу «стартом». Как только со скоростью «угадаем» и связь установится, - сразу в поле Receive появится куча данных. Далее удобнее использовать режим проги Tracer, в котором сообщения не «бегут» а «стоят» на месте, а в них данные меняются. Теперь непосредственно описание сообщений и данных – в принципе все понятно из описания – кто (какой прибор) и с какой периодичностью посылает данные (например, скорость замедлитель получает во 2-м и 3-м байте сообщения от системы круиз контроля, сам замедлитель шлет в 1-ых четырех битах 1-го байта одного из своих сообщений информацию о том включен он или отключен, если включен, то по какой причине (что инициировало его включение в работу – ABS, ASR, transmission control, acceleration pedal и т.д.).) Всего по этому протоколу обмена с десяток различных сообщений, в которых приводится и управляющая и диагностическая иформация. Теперь, что можно сделать дополнительно, кроме непосредственно диагностики. А можно очень просто «откинуть» «подозрительный» прибор, с которым происходит общение по КАН у замедлителя, и вместо него посылать свои данные с помощью той же проги CANwise. Тут, конечно, надо знать что посылать, но процентов 90 описано в самом протоколе, а можно снять логи с заведомо испраного и т.д. – поле деятельности необъятное. Просто хотел сказать на этом примере для авто, оборудованных CAN – прибор за 100 баксов + протоколы обмена > любого самого крутого дилерского сканера