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

Alexo

Ещё раз - удалось связаться с шиной (то есть, каким-то образом увидели, что данные идут и(или) записываются), - значит, "транспортно - стандартный" уровень CAN преодолели. Далее - надо думать, как интерпретировать полученные данные. Это все равно, что получил я, к примеру (пример, кстати, реальный, - из того времени, когда изучал ОБД и у меня на авто как раз периодически высвечивался чек), в 4-м и 5-м байте ответа на запрос 0x7DF 01 03 00 00 00 00 00 00 (идентификатор и 8 байт данных) получил ответное сообщение 0x7E8 04 43 01 08 33 AA AA AA (здесь в принятой форме 16-ричной записи (0x) я указал только для идентификаторов сообщений, хотя данные представлены также в 16-ричной форме) Теперь надо понять, какая информация тут представлена. Для этого берем открытое описание OBD и интерпретируем: "0x7DF" - это идентификатор запроса на диагностику по ОБД стандарту (об этом я прочитал ранее, причем в разных местах, в Вики, на буржуйских сайтах и форумах канхакеров и т.д. и уже знал, с каким идетификатором должно быть это сообщение. Далее нулевой байт этого сообщения имеет значение "01". Этим я сообщаю системе диагностики, опять же по стандарту ОБД, что "далее следует 1 байт с данными, а после него - можно байты не читать, - все равно в них не содержится никакой информации". То есть, нулевой байт определяет длину поля со значащими данными. Следующий (первый) байт имеет значение "03". По стандарту ОБД - это служба, отвечающая за хранение и предоставление по запросу действующих на настоящий момент ошибках. Теперь ответное сообщение: "0x7E8" - идентификатор стандартного ответного сообщения. "04" - то же самое - количество следующих байт с полезной информацией "43" - байт, получаемый суммированием 16-ричных 03 (которое я посылал в запросе) и 40 (40 прибавляется всегда в ответном сообщении если все нормально и запрос корректный и принят) - тем самым подсистема диагностки авто как бы дает понять, что она принимает и обрабатывает запросы. Дальше - непосредственно данные: "01" - количество сообщений, содержащих данные об ошибках (ведь их может быть и не одна) В данном случае - ошибка одна и она вполне вместилась в это же сообщение, так как на код каждой ошибки тратится 2 байта. (Видимо, поместится и две ошибки, просто, соответственно, в нулевом байте будет указана длина поля со значащими данными не 4 а 6.) "08" и "33" - непосредственно код ошибки. Не буду долго расписывать, как он декодируется (можно посмотреть в Вики), скажу только, что прикольно - визуально в 16-ричной системе можно сразу сказать без "особой тренировки", что код ошибки P0833. Далее - по-крайней мере в моем Кобальте незначащие байты заполняются именно АА (может, видимо, быть по другому, однако это не интересует - по нулевому байту можно точно сказать, сколько байт рассматривать). А вот далее - по коду ошибки узнаем, что эта ошибка - датчика положения педали сцепления.. Так вот, все эти "описания" как интерпретировать все данные (получаемые, отсылаемые) и проч. и описаны в открытом протоколе обмена ОБД.

----------

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

Вообще, сообщения делятся на два вида - постоянно "висящие" в шине - это служебные, которой обмениваются блоки как раз по протоколу производителя, некоторая информация из которых понятна, о чем я писал ранее.
В данном случае, во фрагмент кадра попали несколько сообщений между моим запросом и ответом системы.
По времени получения кадра видно, что ответ на запрос пришел примерно через 1 мс.
Интересно, что постоянные служебные сообщения посылаются с периодом менее 1 мс. Это очень быстро - учитывая скорость обмена - 500 кбит/с.
Для эмуляторов это говорит о том, что дешевенькие простенькие контроллеры, допустим ELM327 не справятся с задачей полной эмуляции...

----------

Добавлю - это выполнено при помощи универсального CAN-USB адаптера Marathon.
Можно было, конечно, настроить его аппаратный фильтр для пропуска только интересующих сообщений (настраивается как для одиночного сообщения, так и для группы идентификаторов - по диапазону). Фильтры чаще всего и применяются в подобных случаях - когда в сети много сообщений (сеть сильно загружена), и, чтобы не тратить процессорное время контроллера адаптера и программно-процессорное время непосредственно обрабатывающей системы (например, компа с соответствующей ОС и ПО), и премяняются фильтры.
Как правило, при разработке протоколов обмена стараются скомпоновать сообщения по их идентификаторам наряду с приоритетностью, принадлежностью к тем или иным группам и проч. ещё и из соображений простоты и удобства пользования аппаратной фильтрацией.
Так например, в случае с ОБД при снятии марафоном, - я устанавливаю фильтр (на самом деле в аппаратной фильтрации всегда два параметра - MASK и CODE) и маску и код фильтра в 0x7E0, и адаптер начинает пропускать на обработку сообщения только с идентификаторами из диапазона ОБД.
В том примере, что на рисунке, я аппаратной фильтрацией не пользовался - там мне было интересно, как это все будет коррелировать с другими (служебными) сообщениями...

----------

Так вот - самое главное - реверс - инжениринг и предполагает разобраться во всех этих служебных протоколах конкретного производителя, как это я показал на примере открытого протокола ОБД.
У меня уже есть дешевенькие кан-сканеры vag-com, op-com.
Интересует для GM. Что можно приобрести по цене не выше 5 килорублей?

ddk_f

[QUOTE=Alexo;275580]Для этого берем открытое описание OBD и интерпретируем: "0x7DF" - это идентификатор запроса на диагностику по ОБД стандарту (об этом я прочитал ранее, причем в разных местах, в Вики, на буржуйских сайтах и форумах канхакеров и т.д. и уже знал, с каким идетификатором должно быть это сообщение. Далее нулевой байт этого сообщения имеет значение "01"./QUOTE]

В протоколе "UDS" адрес "0x7DF" для общих команд, к примеру если подать команду вытереть ошибки "14" то откликнутся все блоки на исполнение этой команды.

В пакете первый байт не нулевой а количество байтов , если первая цифра 1Х то пакет длинный , пример 07 - это семь байт а есле 10 08 то это уже 8-мь байт так как он в транспотный КАН не влезает передают его в несколько КАН-посылок. 1F F8 - это передача FF8 hex байт.

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

Alexo

"Нулевой" - в смысле по счету - это для обывателей счет байтов начинается с 1-го по 8-й, для программистов же это ОБЯЗАТЕЛЬНО с 0-го по 7-ой (так же как и биты). Это важно, так как внутреннее представление определенных байтов и бит в контроллере происходит именно так.
С остальным согласен - в стандарте ОБД все расписано, думаю более детально разжевывать смысла нет...

GASCHE

Как то все натянуто, обычно ответ с ID 00 00 07 E8 приходит на запрос ID 00 00 07 E0.

Alexo

На что "натянуто"?.. Что значит "обычно"? А бывает и не приходят?
На 7E0 ТОЖЕ придет аналогичный ответ.

P.S. А чего это обозначение идентификатора с кучей нулей (не лень нули писать), или имелись ввиду 29-битные идентификаторы?..

GASCHE

Значит, что адрес запроса и ответа отличается на 8.
не лень, ID передается 4 битами.

Alexo

Вы вообще представляете предмет, о котором пишите с такой уверенностью?
Вот ещё отдельный запрос и ответ, если не понятен пример, приведенный выше:

Ну и сложите 7DF с 8, если получите в сумме 7E8 - получите премию математического института Клэя.
Вообще - моя прога использует только 7DF - запросы и прекрасно получает 7E8 - ответы по всему ОБД-протоколу.
Насчет - "не лень" - у каждого свои причуды..

ghost_gluck

Alexo, все правильно пишет GASCHE. 7DF, как писал Да вы тоже читали это.
Но есть еще 8 адресов, для каждого из 8 блоков. Т.е. 0x7E0:0x7E8 - пара request/response для первого ECU. Т.е. команды шлем на 0x7E0, а ответ получаем от 0x7E8. И так для каждого последующего ECU.
Например, у меня на посыл команды сброса всех ошибок в 0x7DF - приходит ответ c ID 0x7DC.
Список команд диагностики - см. ISO 15765-3. Chapter 9. Diagnostic service implementation. Посмотрите таблицы 59,60 главы 10.4.2 этого же документа.
Адреса, про которые я писал, вы найдете в ISO 15765-4. Глава 11bit CAN Identifiers.

----------

Сегодня к МАЗу подключиться не удалось, т.к. переходник, которым я пользовался, от Autocom. Других разъемов у меня нет, а автокомовский - литой, раздербанить можно, но не стоит.
Попробую сделать отдельный шнур для МАЗа с пинами и еще разподключиться.

----------

Такое лучше не делать не зная комманд. Не зная номера блока ECU можно нарваться на ECU SRS. Ну и послав что-то не то, могут стрельнуть подушки (тут я утрирую, но все-таки предостережение).
IMHO, Если команда предназначена какому-то блоку единолично, то лучше слать по request ID этого блока.
Как поступать дальше - решать Вам.

Alexo

Да я тоже посылал и все эти 7E0 и иже с ними - ответы идентичны 7DF (хотя у себя в проге по ОБД на всякий случай сделал, что можно изменять идентификатор запроса на любой другой).
Более того - я тоже где-то читал, что в некоторых случаях прибавляется 8-ка. Но, далеко не во всех. Поэтому и сам по-возможности, пока лично не проверю, - не делаю безапеляционных заявлений.
По крайней мере, на Кобальте и Фольксе Т5 2008 г. это так. Кстати, что интересно, на Т5 (но только уже 2004 г.) связаться по кан не удалось - как оказалось, - он там хоть и есть, но - внутренний для межблочного общения а на диагн. разъем не выведен.

----------

Все правильно, однако, вышесказанное следует изложить так - можно посылать любые сообщения с идентификаторами больше 0х7DF без боязни. А вот ниже - действительно надо аккуратно..

ddk_f

В читаемых доках не все описывается.

Базовое это на адрес скажем 7E0 ответ +8 , ну это относится для последних адресов а вот для первых 700, 701... от тут уже не стыковка , одни производители используют +8 а некоторые +40hex и +60hex.

Существуют команды которые не в какой стандарт не входят.

Опыт использования КАН есть в разных проектах в том числе полный эмулятор разных автомобилей и разных брендов.