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

ghost_gluck

ddk_f, еще раз спрашиваю, где я написал про транспортный?

Меня интересовала инкапсуляция пакетов протокола более высокого уровня. Она найдена. Что Вы пытаетесь доказать?

Для новичков Ваша информация будет полезна.

PS. Ничего личного. Но если и это сообщение не донесет до Вас смысл происходящего, тогда и не знаю, как быть. Считаю дальнейшие препирательства на данную тему нецелесобразными.

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 этого блока.
Как поступать дальше - решать Вам.

GASCHE

Смотрим ISO 15765-4 First edition 2005-01-15

6.3.2.2 11 bit CAN identifiers
Table 3 specifies the 11 bit CAN identifiers for legislated OBD, based on the defined mapping of the
diagnostic addresses.

Table 3 — 11 bit legislated-OBD CAN identifiers
CAN identifier Description
(hex)
7DF CAN identifier for functionally addressed request messages sent by external test equipment
7E0 Physical request CAN identifier from external test equipment to ECU #1
7E8 Physical response CAN identifier from ECU #1 to external test equipment
7E1 Physical request CAN identifier from external test equipment to ECU #2
7E9 Physical response CAN identifier from ECU #2 to external test equipment
7E2 Physical request CAN identifier from external test equipment to ECU #3
7EA Physical response CAN identifier from ECU #3 to external test equipment
7E3 Physical request CAN identifier from external test equipment to ECU #4
7EB Physical response CAN identifier ECU #4 to the external test equipment
7E4 Physical request CAN identifier from external test equipment to ECU #5
7EC Physical response CAN identifier from ECU #5 to external test equipment
7E5 Physical request CAN identifier from external test equipment to ECU #6
7ED Physical response CAN identifier from ECU #6 to external test equipment
7E6 Physical request CAN identifier from external test equipment to ECU #7
7EE Physical response CAN identifier from ECU #7 to external test equipment
7E7 Physical request CAN identifier from external test equipment to ECU #8
7EF Physical response CAN identifier from ECU #8 to external test equipment
-----------------------------------------------------
While not required for current implementations, it is strongly recommended (and may be required by applicable
legislation) that for future implementations the following 11-bit CAN identifier assignments be used:
7E0/7E8 for ECM (engine control module);
7E1/7E9 for TCM (transmission control module).
Заметьте что читал не где-то. Поэтому думаю вопрос
вы должны задать в первую очередь себе