Ещё раз - удалось связаться с шиной (то есть, каким-то образом увидели, что данные идут и(или) записываются), - значит, "транспортно - стандартный" уровень 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 килорублей?