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

ghost_gluck

Да, именно это и делал.

Лог получен. Сомнения в протоколе, который используется в легковых авто.

Ну и попутно сомнения с другим прибором (AVL-треккером). Возможно я некорректно с ним работал, т.к. не получил ответ с CAN-шины. Но это уже другая история 8)

Буду парсить лог, результаты трейса выложу позже.

Alexo

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

GASCHE

Hyundai Grand Starex, H-1 после 2007г. ISO-15765.

ghost_gluck

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

Спасибо за подсказку, буду смотреть.

ddk_f

Чтобы "ковырять" КАН в первую очередь нужно осознать что это в первую очередь ТРАНСПОРТНЫЙ ПРОТОКОЛ в который вживили протокол диагностики, сначала каждый производитель делал свое а потом сперва адаптировали общий KWP2000 а потом чтобы навести порядок трансформировали в UDS . Как для "транспортной шины" каждый производитель делает что хочет и передает что хочет.

ghost_gluck

ddk_f, а где я написал про транспортный? Я сомневался в выборе Application Layer

ddk_f

Все что по КАНу это транспортировка данных. Просто пакеты до 8 байт.
Чтобы передать больше надо сделать систему и разные стандарты как раз и это делают.
Стандарты самого КАНа устанавливают физику шины, единую скорость , арбитраж , корекцию ошибок . Только в диагностических стандартах устанавливается формат данных и адресация, тоесть передавать в других свободних адресах возможно что угодно, и что и делают разные производители на свое усмотрение.

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 а при приеме АА но иногда идут нули а иногда ленятся и кеш оперативки.