OBD2 читаем и запоминаем.
m.habr.com/ru/post/444726/
Статья не моя, но коротко и ясно дана почти вся информация по обд. Советую к прочтению и сохраню для истории.
При создании приложения мы столкнулись с множеством выборов, проблем и так далее, с которыми попробуем ознакомить вас в этой статье. Как оказалось с автомобилем можно вести диалог, причем довольно таки продуктивный. Естественно для того чтобы организовать общение с автомобилем необходимо «установить контакт», «задать правильный вопрос» и правильно понять «ответ», полученный от автомобиля. Соответственно статья и будет нацелена на то, чтобы доступным языком объяснить организацию диалога, а также рассказать вам какие ошибки могут встретиться вам на пути и как с ними бороться.
Изначально необходимо пояснить что для подключения к авто будет использоваться ELM327 адаптер. ELM327 – это микросхема, которая позволяет преобразовать протоколы, используемые в диагностических шинах автомобилей в протокол RS232, которым мы и будем передавать данные. За счет того что передача данных по протоколу RS232 происходит последовательно возникает первая проблема – скорости передачи данных, которую мы постараемся обойти в одном из следующих пунктов.
Существует несколько вариаций адаптера ELM327, которые классифицируются по способу передачи данных – Bluetooth, WIFI, USB. Исходя из того что целью разработки является мобильное устройство под операционной системой Android можно подобрать две наиболее подходящие версии ELM327, такие как Bluetooth и WIFI. Так как способ получения и обработки данных один, а отличаются они всего лишь вариантами подключения к адаптеру, то можно выбрать всего один, организовать при помощи него диалог, а после добавить остальные варианты подключения.
ELM327 1.5 vs ELM327 2.1
Одной из первых проблем, с которыми можно столкнуться стала проблема выбора непосредственно адаптера, в нашем случае Bluetooth. Оказывается если вам необходимо поддерживать все (по крайней мере большинство) автомобилей необходимо выбирать версию v1.5 вместо v2.1, что на самом то деле необходимо несколько раз уточнить при покупке адаптера, потому как продавцы пытаются выдать версию адаптера не за ту, которая есть на самом деле, т.к. они особо ничем не отличаются. На деле же в версии v2.1 отсутствует поддержка протоколов J1850 PWM и J1850 VPW, что говорит о том, что у вас не получится подключиться к автомобилям, которые используют эти протоколы.
Подключение к адаптеру происходит в несколько этапов:
Подключение к адаптеру (Bluetooth, WIFI)
Отправка инициализационных команд (инициализационной строки)
Если с организацией подключения все понятно. Принцип работы такой же как и у любого Bluetooth/WIFI чата. То для того чтоб понять как отправлять инициализационную строку, необходимо изучить какие команды существуют, а также какие функции они выполняют.
AT Z [reset all]
Сброс настроек адаптера до заводского состояния.
AT L1-0
Включить/Отключить символы перевода строки.
AT E1-0
Echo on – off
AT H1-0
Headers on – off
AT AT0-1-2
Adaptive Timing Off — adaptive Timing Auto1 — adaptive Timing Auto2
AT ST FF
Установить таймаут на максимум.
AT D [set all to Default]
Сброс настроек в исходное, настроенное пользователем состояние.
AT DP [Describe the current Protocol]
Сканер способен самостоятельно определять протокол автомобиля, к которому он подключен.
AT IB10 [set the ISO Baud rate to 10400]
Команда устанавливает скорость обмена данных для ISO 9141-2 и
ISO 14230-4 10400
AT IB96 [ set the ISO Baud rate to 9600]
Команда устанавливает скорость обмена данных для ISO 9141-2 и
ISO 14230-4 9600 для протоколов 3,4,5.
AT SP h [ Set Protocol h]
Команда выбора протокола h, где h:
0 – Automatic;
1 — SAE J1850 PWM (41.6 Kbaud);
2 — SAE J1850 VPW (10.4 Kbaud);
3 — ISO 9141-2 (5 baud init, 10.4 Kbaud);
4 — ISO 14230-4 KWP (5 baud init, 10.4 Kbaud);
5 — ISO 14230-4 KWP (fast init, 10.4 Kbaud);
6 — ISO 15765-4 CAN (11 bit ID, 500 Kbaud);
7 — ISO 15765-4 CAN (29 bit ID, 500 Kbaud);
8 — ISO 15765-4 CAN (11 bit ID, 250 Kbaud);
9 — ISO 15765-4 CAN (29 bit ID, 250 Kbaud);
AT SP Ah [Set Protocol h with Auto]
Команда устанавливает по умолчанию протокол h, если подключение по протоколу h не удалось, тогда адаптер начинает автоматический подбор протокола.
Исходя из описанных выше команд, формируем инициализационную строку.
initializeCommands
= Arrays.asList(«ATZ», «ATL0», «ATE1», «ATH1», «ATAT1», «ATSTFF», «ATDP», «ATSP0»);
Желательно давать возможность пользователю сменять инициализационные команды, потому как для того чтобы подобрать «ключ» к некоторым авто необходимо выбрать более подходящие настройки адаптера. В нашем же случае используются настройки, которые походят для большинства стандартных протоколов.
Так же желательно обратить внимание на команду APSP0, таким образом мы устанавливаем по умолчанию автоматический подбор протокола, это может занять некоторое время.
Соответственно если пользователь знает какой у его авто протокол, то используя возможность смены протокола подключения он может поменять 0 на номер его протокола.
Считывание диагностических данных
Для считывания диагностических данных используются специальные команды PID’s.
PID (Parameter id’s — Бортовые диагностические идентификаторы параметров) – коды, которые используются для запроса показателей определенных датчиков автомобиля.
Основные пиды можно найти в Википедии, там полный набор основных команд, которые должны поддерживать все автомобили. Так же есть наборы команд для определенных марок и типов автомобилей, эти наборы предоставляются за отдельную плату. В нашем случае приложение заточено на базовую диагностику автомобилей соответственно мы используем базовый набор команд.
Также есть возможность получать текущие данные от автомобиля при этом команда получения данных от авто будет иметь вначале 01, указывая на то что мы хотим получить real data. Если же мы хотим получить сохраненные данные автомобиля, то вначале команды необходимо указать 02. Например, команда для получения текущей скорости автомобиля – 010D, а для получения сохраненной скорости – 020D.
Если внимательно посмотреть на то количество команд, которое предоставляется открытыми ресурсами, то можно как раз и заметить ту проблему, о которой я писал в самом начале, а именно проблема скорости ответа адаптера. Так как отправка и получение команд идет последовательно, то для того чтобы получить показания датчика на текущий момент времени необходимо дождаться ответа на все предыдущие команды. Соответственно если запрашивать на получение все команды, то большая вероятность того что обновление реальных данных будет происходить очень медленно. Но и эту проблему можно решить, если воспользоваться командами, которые отобразят только те команды, что существуют в автомобиле. Например:
0100 – PIDs supported [01 — 20]
0120 – PIDs supported [21 — 40]
0140 – PIDs supported [41 — 60]
0160 – PIDs supported [61 — 80]
0180 – PIDs supported [81 – A0]
01A0 – PIDs supported [A1 — C0]
Я продемонстрирую как определить какие датчики присутствуют в автомобиле при помощи одного из пидов. Например:
0100 \\ запрос
BB1E3211 \\ ответ от авто
Переводим ответ от автомобиля в двоичную систему счисления
Используя следующую табличку можем определить какие пиды поддерживаются нашим автомобилем, начиная от 01 до 20:
Исходя из получившихся данных можем определить, что наш автомобиль поддерживает следующие пиды:
01, 03, 04, 05, 07, 08, 0C, 0D, 0E, 0F, 13, 14, 17, 1C, 20
Теперь вместо отправки всех 32 команд и ожидания ответа на них, несмотря на то, что некоторые могут отсутствовать, мы будем использовать всего 15 команд. Но и это не предел так называемой оптимизации. Для того чтобы данные обновлялись еще быстрее советую запрашивать только данные о тех датчиках, которые отображаются на экране. Хотя это ограничивает некоторый функционал приложения. Например, запись истории.
Считывание и расшифровка ошибок автомобиля
Ошибки автомобиля тоже могут быть различными и для них тоже существуют отдельные команды. Например:
03 – Для отображения сохраненных кодов ошибок
0A – Для отображения постоянных кодов ошибок.
Так как и с остальными командами ошибки автомобиля приходят в закодированном виде, соответственно, как и в остальных командах их нужно раскодировать чтоб получить необходимую информацию. Приведу пример работы декодирования ошибки. Код:
private final static char[] dtcLetters = ;
private final static char[] hexArray = «0123456789ABCDEF».toCharArray();
private void performCalculations(String fault) final String result = fault;
String workingData = «»;
int startIndex = 0;
troubleCodesArray.clear();
try if (result.contains(«43»)) workingData = result.replaceAll(«^43|[\r\n]43|[\r\n]», «»);
> else if (result.contains(«47»)) workingData = result.replaceAll(«^47|[\r\n]47|[\r\n]», «»);
>
for(int begin=startIndex; begin < workingData.length(); begin += 4) String dtc = "";
byte b1 =
Utility.hexStringToByteArray(workingData.charAt(begin));
int ch1 = ((b1 & 0xC0) >> 6);
int ch2 = ((b1 & 0x30) >> 4);
dtc += dtcLetters[ch1];
dtc += hexArray[ch2];
dtc += workingData.substring(begin + 1, begin + 4);
if (dtc.equals(«P0000»)) continue;
>
troubleCodesArray.add(dtc);
>
> catch (Exception e) Log.e(TAG, «Error: » + e.getMessage());
>
>
А теперь пояснение.
Исходя из полученного ответа мы можем получить код ошибки, для этого декодируем полученное сообщение используя следующие таблички.
3, 4, 5 символы формируются по этой таблице:
Исходя из этого можем попробовать разобрать следующий ответ 0001000000111110
Код ошибки: P103E
На данном этапе мы разобрались в том, каким образом организовать диалог с адаптером, посылать ему команды, получать и расшифровывать его ответы. Это большая часть работы, если считать то, сколько времени уходит на изучение материала, но в то же время довольно таки интересная. За пределами этой статьи осталось множество проблем связанных с визуальным интерфейсом, а также множество дополнительных функций, таких как добавление новых пидов из файла, стандартный и расширенный способ подключения к адаптеру и построения графиков.
Как узнать протокол эбу автомобиля
OBD-II для диагностики автомобилей:
основная информация
Вместе с ростом экологического движения в начале 1990-х годов в США был принят ряд стандартов, которые ввели обязательность оснащения электронных блоков управления автомобилями (ЭБУ, ECU) системой за контролем параметров работы двигателя, имеющих прямое или косвенное отношение к составу выхлопа. Стандарты также предусмотрели протоколы считывания информации об отклонениях в экологических параметрах работы двигателя и другой диагностической информации из ЭБУ. OBD-II как раз и является системой накопления и считывания такой информации. Изначальная «экологическая направленность» OBD-II, с одной стороны, ограничила возможности по его использованию в диагностике всего спектра неисправностей, с другой стороны, предопределила его крайне широкое распространение как в США, так и на автомобилях других рынков. В США применение системы OBD-II (и установка соответствующей колодки диагностики) обязательны с 1996 г. (требование распространяется как на автомобили, производимые в США, так и на автомобили неамериканских марок, продаваемые в США). На автомобилях Европы и Азии протоколы OBD-II применяются также с 1996 г. (на небольшом количестве марок/моделей), но особенно — с 2001 г. для автомобилей с бензиновыми двигателями (с принятием соответствующего европейского стандарта — EOBD) и с 2004 г. для автомобилей с дизельными двигателями. Тем не менее, стандарт OBD-II частично или полностью поддерживают и некоторые автомобили, выпущенные ранее 1996 (2001) годов (pre-OBD автомобили).
Протоколы OBD-II предоставляют диагносту ряд стандартизированных функциональных возможностей (режимов диагностики — modes):
Режим 1 — Считывание текущих параметров работы системы управления (Mode 1 PID Status & Live PID Information). Всего стандартом поддерживается около 20 параметров. Однако, каждый конкретный блок управления поддерживает ограниченное количество из них (например, в зависимости от установленных датчиков кислорода). С другой стороны, некоторые автопроизводители поддерживают расширенные наборы параметров — например, некоторые автомобили концерна GM поддерживают более 100 параметров. Через систему OBD-II диагностики можно считать (основные параметры):
— режим работы системы топливной коррекции (PID 03 Fuel system status). При значении «Closed Loop» система работает в режиме обратной связи (замкнутой петли), при этом данные с датчика кислорода используются для корректировки топливоподачи. При значении «Open Loop» данные с датчика кислорода не используются для корректировки топливоподачи;
— расчетная нагрузка на двигатель (PID 04 Calculated Load);
— температура охлаждающей жидкости (PID 05 Coolant temperature);
— краткосрочная коррекция подачи топлива по банку 1/2 (PID 06/08 Short Term Fuel Trim Bank 1/2);
— долгосрочная коррекция подачи топлива по банку 1/2 (PID 07/09 Long Term Fuel Trim Bank 1/2);
— давление топлива (PID 0A Fuel pressure);
— давление во впускном коллекторе (PID 0B Manifold pressure);
— обороты двигателя (PID 0C Engine speed — RPM);
— скорость автомобиля (PID 0D Vehicle speed);
— угол опережения зажигания (PID 0E Ignition Timing Advance);
— температура всасываемого воздуха (PID 0F Intake Ait Temperature);
— расход воздуха (PID 10 Air Flow);
— положение дроссельной заслонки (PID 11 Throttle position);
— режим работы системы подачи дополнительного воздуха (PID 12 Secondary Air Status);
— расположение датчиков кислорода (PID 12 Location of O2 sensors);
— данные с датчика кислорода №1/2/3/4 по банку 1/2 (PID 13-1B O2 Sensor 1/2/3/4 Bank 1/2 Volts).
Как правило, для анализа работы конкретной подсистемы системы управления двигателем, достаточно одновременно контролировать 2-3 параметра. Однако, иногда требуется одновременно просматривать и большее число. Число одновременно контролируемых параметров, а также формат их вывода (текстовый и/или графический) зависят как от возможностей конкретной программы-сканера, так и от скорости обмена информацией с блоком управления двигателем автомобиля (скорость зависит от поддерживаемого протокола). К сожалению, наиболее распространенный протокол ISO-9141 (см. ниже) является и самым медленным из всех — при работе с ним невозможно просматривать с приемлемой частотой дискретизации более 2-4 параметров.
Режим 2 — Получение сохраненной фотографии текущих параметров работы системы управления на момент возникновение кодов неисправностей (Mode 2 Freeze Frame).
Режим 3 — Считывание и просмотр кодов неисправностей (Mode 3 Read Diagnostic Trouble Codes (DTCs)).
Режим 4 — Очистка диагностической памяти (Mode 4 Reset DTC’s and Freeze Frame data) — стирание кодов неисправностей, фотографий текущий параметров, результатов тестов датчиков кислорода, результатов тестовых мониторов.
Режим 5 — Считывание и просмотр результатов теста датчиков кислорода (Mode 5 O2 Sensor Monitoring Test Result).
Режим 6 — Запрос последних результатов диагностики однократных тестовых мониторов (тестов, проводимых один раз в течение поездки) (Mode 6 Test results, non-continuosly monitored) — эти тесты контролируют работу катализатора, системы рециркуляции выхлопных газов (EGR), системы вентиляции топливного бака.
Режим 7 — Запрос результатов диагностики непрерывно действующих тестовых мониторов (тестов, выполняемых постоянно, пока выполняются условия для проведения теста) (Mode 7 Test results, continuosly monitored) — эти тесты контролируют состав топливо-воздушной смеси, пропуски зажигания (misfire), остальные компоненты, влияющие на выхлоп.
Режим 8 — Управление исполнительными механизмами.
Режим 9 — Запрос информации о диагностируемом автомобиле (Mode 9 Request vehicle information) — VIN-кода и калибровочных данных.
Режим ручного ввода команды запроса диагностической информации.
Надо учитывать, что как далеко не на каждом автомобиле блок управления поддерживает все перечисленные функции, так и не каждый диагностический сканер для OBD-II может дать диагносту возможность использовать все перечисленные режимы.
Используемые протоколы и применяемость OBD-II-диагностики на автомобилях разных марок
В рамках OBD-II используются пять протоколов обмена данными — ISO 9141, ISO 14230 (также именуется KWP2000), PWM, VPW и CAN (также каждый из протоколов имеет несколько разновидностей — например, разновидности отличаются по скорости обмена информацией). В Интернете встречаются «таблицы применимости», где указываются перечни марок и моделей автомобилей и поддерживаемые ими OBD-II-протоколы. Ознакомиться с одной из таких таблиц можно и на нашем сайте. Однако, надо учитывать, что одна и та же модель с одним и тем же двигателем, одного года выпуска может быть выпущена для разных рынков с поддержкой разных протоколов диагностики (точно также протоколы могут различаться и по моделям двигателей, годам выпуска). Таким образом, отсутствие автомобиля в списках не означает, что он не поддерживает OBD-II, так же как и присутствие не означает, что поддерживает и, тем более, полностью поддерживает (возможны неточности в списке, различные модификации автомобиля и пр.). Еще сложнее судить о поддержке конкретной разновидности OBD-II-стандарта.
Общей предпосылкой для того, чтобы предположить, что автомобиль поддерживает OBD-II диагностику, является наличие 16-контактного диагностического разъема (DLC — Diagnostic Link Connector) трапециевидной формы (на подавляющем большинстве OBD-II автомобилей он находится под приборной панелью со стороны водителя; разъем может быть как открыт, так и закрыт легко снимаемой крышкой с надписью «OBD-II», «Diagnose» и т.п.). Тем не менее, это условие необходимое, но недостаточное! Получить справку о расположении разъемов (в том числе нестандартном) можно на странице «Техподдержка» нашего сайта. Также разъем OBD-II иногда устанавливается на автомобили, вообще не поддерживающие ни один из OBD-II-протоколов. В таких случаях необходимо пользоваться сканером, рассчитанным на работу с заводскими протоколами конкретной марки автомобиля — например, это касается автомобилей Opel Vectra B европейского рынка 1996-1997 гг. Для оценки применимости того или иного сканера для диагностики конкретного автомобиля необходимо определить, какой конкретно из OBD-II протоколов используется на конкретном автомобиле (если OBD-II вообще поддерживается). Для этого можно:
1. Посмотреть в технической документации непосредственно к данному автомобилю (но не в общем руководстве по данной марке/модели!). Также полезно осмотреть все идентификационные таблички на автомобиле — возможно наличие таблички «OBD-II compliant» (поддерживает OBD-II) или «OBD-II certified» (сертифицировано на поддержку OBD-II);
2. Посмотреть в информационной базе данных, типа Mitchell-on-Demand и т.п. Однако, это также не абсолютный способ, так как база может содержать неточности, включать информацию по автомобилям, выпущенным для другого рынка и т.п. Естественно, использование специализированных дилерских баз по отдельной марке повышает степень достоверности информации;
3. Использовать сканер, позволяющий определить, какой из OBD-II протоколов используется на машине. Из предлагаемых нами приборов автоматически это сможет сделать Х-431 и OZEN MOByDic 2600. С помощью комплекта ScanTool Вы сможете это сделать вручную путем последовательной смены используемых адаптеров и проверки наличия связи с ЭБУ автомобиля. Если никаких предположений по используемому протоколу нет, то начинать перебор стоит с протокола ISO как наиболее распространенного (либо с протокола, указанного для диагностируемой машины в таблице);
4. Осмотреть диагностический разъем и определить наличие выводов в нем (как правило, присутствует только часть задействованных выводов, а каждый протокол использует свои выводы разъема).
Назначение выводов («распиновка») 16-ти контактного диагностического разъема OBD-II (стандарт J1962):
02 — J1850 Bus+
04 — Chassis Ground
05 — Signal Ground
06 — CAN High (J-2284)
07 — ISO 9141-2 K-Line
10 — J1850 Bus-
14 — CAN Low (J-2284)
15 — ISO 9141-2 L-Line
16 — Battery Power (напряжение АКБ)
По наличию выводов можно ориентировочно судить об используемом протоколе при помощи следующей таблицы:
— протокол ISO-9141-2 идентифицируется наличием контакта 7 в диагностическом разъеме (K-line) и отсутствием 2 и/или 10 контактов в диагностическом разъеме. Используемые выводы — 4, 5, 7, 15 (может не быть), 16.
— SAE J1850 VPW (Variable Pulse Width Modulation). Используемые выводы — 2, 4, 5, 16 (без 10)
— SAE J1850 PWM (Pulse Width Modulation). Используемые выводы — 2, 4, 5, 10, 16.
Протоколы PWM, VPW идентифицируются отсутствием контакта 7 (K-Line) диагностического разъема.
5. Подавляющее большинство автомобилей используют протоколы ISO. Некоторые исключения:
— большая часть легковых автомобилей и легких грузовиков концерна GM используют протокол SAE J1850 VPW;
— большая часть автомобилей Ford использует протокол J1850 PWM.
Дополнительные сведения об OBD-II диагностике.
В рамках OBD-II стандартизированы не только назначения выводов диагностического разъема, его форма и протоколы обмена, но и частично стандартизированы и коды неисправностей (DTC — Diagnostic Trouble Code) — это предусмотрено стандартом SAE J2012). OBD-II-коды имеют единый формат, однако по их расшифровкам подразделяются на две большие группы — основные (generic) коды и дополнительные (расширенные, extended) коды. Основные коды жестко стандартизированы и их расшифровка одинакова для всех автомобилей, поддерживающих OBD-II. При этом надо понимать, что это не означает, что один и тот же код вызывается на разных автомобилях одной и той же «реальной» неисправностью (это зависит от особенностей конструкции как разных марок и моделей авто, так и разных автомобилей одной модели)! Дополнительные коды различаются по разным маркам автомобилей и были введены автопроизводителями специально для расширения возможностей диагностики.
Как уже говорилось, структура и основных и дополнительных OBD-II кодов одинакова — каждый код состоит из буквы латинского алфавита и четырех цифр (частично уже используются и буквы):
U1XXX, U2XXX — MFG — код, определенный производителем (extended)
Узнать расшифровку OBD-II кодов неисправностей (всех основных и части расширенных) можно в нашем справочнике кодов, а также в информационных базах данных.
Приобрести любой из перечисленных в данной статье или в нашем каталоге сканеров можно обратившись в нашу фирму.
© АРДИО РУ, Виснап К.Н. Последнее обновление статьи 08.10.2005. Перепечатка только с согласия автора и с обязательной ссылкой.
Как узнать протокол эбу автомобиля
Диагностика бортового оборудования OBD-II
Большинство современных автомобилей оснащено сейчас электронным блоком управления (ЭБУ) постоянно собирающим и анализирующим данные в реальном времени о режимax работы двигателя, системы подачи топлива, температуре охлаждающей жидкости и других компонентов автомобиля. OBD-II — On Board Diagnostic (диагностика бортового оборудования) автомобиля это технология диагностирования ЭБУ при помощи компьютера или специализированного диагностического тестера. Спецификация была разработана Society of Automotive Engineers (SAE) и принята как обязательная в США для всех автомобилей выпускающихся с 1996 года. Изначально OBD-II предназначалась для для контроля параметров имеющих отношение к эмиссии. Это ограничивает ее возможности для контроля и дигностирования всего спектра параметров современного автомобиля, но обусловило ее широкое распространение в виду «экологической ориентированности». OBD-II использует 5 протоколов обмена данными:
- ISO 9141-2
- ISO 14230-4
- SAE PWM J1850 (Pulse-Width Modulation)
- SAE VPW J1850 (Variable Pulse Width)
- ISO 15765-4 Controlled Area Network (CAN)
Назначение выводов разьема приведено в таблице. Использование контактов 1, 3, 8, 9, 11-13 стандартом SAE не определо и производили могут использовать их по своему усмотрению.
| Контакт | Назначение |
|---|---|
| 1 | Не определен |
| 2 | Положительня линия SAE J1850 |
| 3 | Не определен |
| 4 | Корпус |
| 5 | Общий |
| 6 | CAN(H)ISO 15765 |
| 7 | K линия ISO 9141/14230 |
| 8 | Не определен |
| 9 | Не определен |
| 10 | Отрицательная линия SAE J1850 |
| 11 | Не определен |
| 12 | Не определен |
| 13 | Не определен |
| 14 | CAN(L) ISO 15765 |
| 15 | L линия ISO9141/142300 |
| 16 | +12 вольт батареи |
Что может дать OBD-II? Достаточно много, он позволяет определять и стирать коды неисправности, контролировать параметры работы двигателя в реальном времени, считывать информацию о серийном номере автомобиля и пр. Однако для чип-тюнинга производители используют собственные нестандартные проколы достула к ЭБУ, совместимые по электрических параметрам с ISO 9141/14230, например KW1281 (Audi, Volkswagen, Seat, Skoda), KW71 (BMW), KW82 (Opel). В новых автомобилях используется CAN протокол как для OBD-II так и для чип-тюнинга.
Выводы разъемы для Toyota/Lexus, источник pinoutsguide.com
| Pin | Signal | Description |
|---|---|---|
| 2 | J1850 Bus+ | |
| 4 | CGND | Chassis ground |
| 5 | SGND | Signal ground |
| 6 | CAN High | J-2284 |
| 7 | K-LINE | (ISO 9141-2 and ISO/DIS 14230-4) |
| 10 | J1850 Bus- | |
| 13 | TC | Timing check — ignition advance angle adjustment or ABS slow codes out |
| 14 | CAN Low | J-2284 |
| 15 | ISO 9141-2 L-LINE | (ISO 9141-2 and ISO/DIS 14230-4) |
| 16 | +12V | Battery power |
Использование протколов:
1999-2003: ISO 9141
2004-2006: ISO 9141 or CAN
с 2007: TBD
Поддерживает ли мой автомобиль OBD-II?
Как определить какой протокол поддерживает электронным блоком управления автомобиля? Первое – можно поискать информацию в Инернете, хотя там много неточной и непроверенной информации. К тому же, многие автомобили выпускаются для разных рынков с различными протоколами диагностики. Второе – найти разьем и посмотреть какие контакты в нем присуствуют. Разьем обычно находистя под приборной панелью со стороны водителя. Протокол ISO 914-2 или ISO 14230-4 определяется наличием контакта 7 и отсуствием контактов 2 и 10, как показано в таблице. Замечу, что контакта 15 скорее всего не будет, так как L линия сегодня почти не используется.
| Протокол | Pin 2 | Pin 6 | Pin 7 | Pin 10 | Pin 14 |
|---|---|---|---|---|---|
| ISO 9141/14230 | + | ||||
| J1850 PWM | + | + | |||
| J1850 VPW | + | ||||
| ISO 15765 CAN | + | + |
EOBD стал стандартом в Европе начиная с 2001 года, а для дизельных двигателей начиная с 2004. Если ваш автомобиль выпущен до 2001 года то он может вообще не поддерживать OBD даже при наличии соответсвуещего разьема! Евросоюз даже оштрафовал Peugeot за не соответвие EOBD стандарту и после 2001 года. Например, Renault Kangoo 99 года не поддерживает EOBD, а Renault Twingo поддерживает! Те же самые автомобили сделанные для других рынков, например Турции, могут тоже не быть совместимыми с OBD протоколом. Вот далеко не полный список ЭБУ до 2001 года которые могут не поддерживать OBD:
- Alfa Romeo
- Citroen
- Fiat
- Peugeot
- Renault
OBD II Руководство пользователя
- $01 Вывод параметров в реальном времени (Real-time powertrain data)
- $02 Вывод «сохраненного кадра параметров» (Freeze Frame)
- $03 Считывание сохраненных кодов неисправностей (Read Stored DTC)
- $04 Стирание кодов неисправностей, сброс статуса мониторов (Clear / Reset diagnostic related information )
- $05 Вывод результатов мониторинга датчика кислорода (O2 monitoring test results)
- $06 Вывод результатов мониторинга для непостояннотестируемых систем ( Monitiring test results for non — continuosly monitored systems )
- $07 Вывод результатов мониторинга для постоянно тестируемых систем ( Monitiring test results for continuosly monitored systems )
- $08 Управление исполнительными компонентами (Bidirectional controls)
- $09 Вывод идентификационных параметров автомобиля (Vehicle information)
Начнем с режима $01 – Real-time powertrain data.
В этом режиме на дисплей сканера выводятся текущие параметры блока управления. Эти параметры можно разделить на три группы. Первая группа – это статусы мониторов. Что такое монитор и зачем ему статус? В данном случае мониторами называются специальные подпрограммы блока управления, которые отвечают за выполнение весьма изощренных диагностических тестов. Существует два типа мониторов. Постоянные мониторы осуществляются блоком постоянно, сразу после пуска двигателя. Непостоянные активируются только при строго определенных условиях и режимах работы двигателя (см. также режимы$06 и $07). Именно работа подпрограмм-мониторов во многом обуславливает мощные диагностические возможности контроллеров нового поколения. Если перефразировать известную поговорку, можно сказать так: «Диагност спит – мониторы работают». Правда, наличие тех или иных мониторов сильно зависит от конкретной модели автомобиля, то есть некоторые мониторы в данной модели могут отсутствовать. Теперь несколько слов о статусе. Статус монитора может принимать только один из четырех вариантов – «поддерживается», «не поддерживается», «завершен» или «незавершен». Таким образом, статус монитора – это просто признак его состояния. Вот эти статусы и выводятся на дисплей сканера. Если в строках «статусы мониторов» высвечиваются символы «завершен», и при этом коды неисправностей отсутствуют, можете не сомневаться, проблем нет. Если же какой-либо из мониторов не завершен, нельзя с уверенностью говорить о том, что система функционирует нормально, необходимо либо отправляться на тест-драйв, либо попросить владельца автомобиля приехать еще раз через какое-то время (более подробно об этом – см. режим $06). Вторая группа – это PIDs, parameter identification data. Что это такое? Это основные параметры, характеризующие работу датчиков, а также величины, характеризующие управляющие сигналы. Анализируя значения этих параметров, квалифицированный диагност может не только ускорить процесс поиска неисправности, но и прогнозировать появление тех или иных отклонений в работе системы. Стандарт OBD II регламентирует обязательный минимум параметров, вывод которых должен поддерживаться блоком управления.
Температура охлаждающей жидкости
Температура всасываемого воздуха
Расход воздуха и/или Абсолютное давление во впускном коллекторе
Относительное положение дроссельной заслонки
Угол опережения зажигания
Значение рассчитанной нагрузки
Частота вращения коленчатого вала
Скорость автомобиля
Напряжение датчика (датчиков) кислорода до катализатора
Напряжение датчика (датчиков) кислорода после катализатора
Показатель (показатели) топливной коррекции
Показатель (показатели) топливной адаптации
Статус (статусы) контура (контуров) лямбда
Если сравнить этот список с тем, что можно «вытащить» из того же самого блока, обратившись к нему на его родном языке, то есть по заводскому (ОЕМ) протоколу, выглядит он не очень впечатляюще. Малое количество «живых» параметров – один из минусов стандарта OBD II. Однако в подавляющем большинстве случаев этого минимума вполне достаточно. Есть еще одна тонкость: выводимые параметры уже интерпретированы блоком управления (исключением являются сигналы датчиков кислорода), то есть в списке нет параметров, характеризующих физические величины сигналов. Например, нет параметров, отображающих значения напряжения на выходе датчика расхода воздуха, напряжения бортсети, напряжения с датчика положения дроссельной заслонки и т.п. – выводятся только интерпретированные значения (см. список выше). С одной стороны, это не всегда удобно. С другой – работа по «заводским» протоколам часто также вызывает разочарование именно потому, что производители увлекаются выводом физических величин, забывая про такие важные параметры, как массовый расход воздуха, расчетная нагрузка и т.п. Показатели топливной коррекции/адаптации (если вообще выводятся) в заводских протоколах часто представлены в очень неудобной и малоинформативной форме. Во всех этих случаях использование протокола OBD II позволяет получить дополнительные преимущества. К особенностям OBD-протоколов относится также сравнительно медленная передача данных. Наибольшая скорость обновления информации, доступная для этого протокола – не более десяти раз в секунду. Поэтому не стоит выводить на дисплей большое количество параметров. При одновременном выводе четырех параметров частота обновления каждого параметра составит 2,5 раза в секунду, что вполне адекватно регистрируется нашим зрением. Примерно такая же частота обновления характерна для многих заводских протоколов 90-х годов. Если количество одновременно выводимых параметров увеличить до десяти, эта величина составит всего один раз в секунду, что во многих случаях просто не позволяет нормально анализировать работу системы. Третья группа – это всего один параметр, к тому же не цифровой, а параметр состояния. Имеется в виду информация о текущей команде блока на включение лампы Check Engine (включена или выключена). Догадываетесь зачем? Очевидно, что и в Америке есть «специалисты» по подключению этой лампы параллельно аварийной лампочке давления масла. По крайней мере, такие факты уже были известны разработчикам OBD-II. Напомним, что лампа Check Engine (американские диагносты любовно называют эту лампу Check Money Light) загорается при обнаружении блоком отклонений или неисправностей, приводящих к увеличению вредных выбросов более чем в 1,5 раза по сравнению с допустимыми на момент выпуска данного автомобиля. При этом происходит запись соответствующего кода (или кодов) неисправности в память блока управления (см. режим $03). Если блок фиксирует пропуски воспламенения смеси, опасные для катализатора, лампочка начинает моргать.
$02 (Freeze Frame)
Обращение к этому пункту меню имеет смысл только в том случае, если в памяти блока управления имеются коды неисправностей (режим $03). В этом случае на дисплей выводится сохраненный блоком кадр тех значений параметров, которые были зафиксированы в момент принятия решения о записи кода. Иными словами, это «моментальный снимок» совокупности PIDs (см. режим $01). Зачем это нужно? Во-первых, знание условий, при которых возникла неисправность, уже само по себе облегчает дальнейший ее поиск. Но все же не это главное. Гораздо в большей степени данные из «замороженного» кадра нужны для того, чтобы как можно точнее воспроизвести эти условия при проведении тестовой поездки, когда всю диагностическую работу выполняет сам блок управления, активируя уже упомянутые выше мониторы. И еще один момент. Кодов неисправности в памяти контроллера может быть много, а вот «замороженный кадр» – как правило, только один (по крайней мере, так поступает большинство производителей). Номер кода неисправности, которому соответствует сохраненный кадр можно найти в том же самом же кадре, обычно он высвечивается в самом начале списка параметров.
$03 (Read Stored DTC)
Сканер производит запрос на считывание кодов неисправностей из памяти блока управления, а блок соответственно эти коды либо выдает, либо пишет, что их нет. Вполне традиционная и наиболее употребляемая диагностами всего мира процедура. Для кодов стандарта OBD II была разработана удобная и информативная система обозначений – буква и четыре цифры (см. рис 1). Эту систему безоговорочно приняло большинство автопроизводителей, причем не только для OBD II, но и для ОЕМ-протоколов. Первая позиция (то есть буква) обозначает тип системы – P (Powertrain), C (Chassis), B (Body) и U (Network). На рынке пока не так много автомобилей, у которых токсичность зависит от работы, например кузовных систем (хотя это абсолютно реально!). Как уже говорилось выше, практическое использование протокола OBD II пока в большей степени ориентировано на силовой агрегат, поэтому речь пойдет о кодах группы Р. Вторая позиция отвечает за степень «крутизны» кода. Все коды с нулевым расширением (Р0) являются базовыми (их еще называют Generic). Один и тот же базовый код описывает одинаковую неисправность, вне зависимости, с какого автомобиля производится считывание. Например, код Р0102 означает одну и ту же проблему для любого автомобиля, поддерживающего требования OBD II / EOBD – низкий уровень сигнала датчика расхода воздуха. Сканер уровня GST может считывать и расшифровывать только коды группы P0. Расширенные коды (Р1ххх, Р2ххх и т.п.), даже если имеют одинаковый номер, имеют разную расшифровку для разных производителей. Например, для Mazda код P1101 означает отклонения от нормы уровня сигнала датчика расхода воздуха, а аналогичный код для Mitsubishi – наличие проблем в цепи вакуумного соленоида противо-буксовочной системы. Пока такие коды являются привилегией производителей автомобилей и это, конечно, создает проблемы для независимых СТО. Расшифровка ОЕМ-кодов под силу только весьма продвинутым OBD-II приборам, хотя следует признать, что даже хорошие универсальные сканеры, работающие по заводским протоколам с этой задачей справляются далеко не всегда (дилерские приборы естественно не в счет). Однако постепенно ситуация меняется в лучшую сторону. Третья позиция (или вторая цифра) в обозначении кода призвана идентифицировать определенную функцию, выполняемую блоком управления, либо подсистему блока, а именно: 1 – измерение нагрузки и дозирование топлива; 2 – подача топлива, система наддува; 3 – система зажигания и регистрация пропусков воспламенения смеси; 4 – системы уменьшения токсичности; 5 – система холостого хода, круиз-контроль, система кондиционирования; 6 – внутренние цепи и выходные каскады блока управления; 7 и 8 – трансмиссия (АКП, сцепление и т.п.) Ну и, наконец, четвертая и пятая позиции – это собственно номер кода, идентифицирующий цепь или компонент.
$04 (Clear/information)
Выбрав этот режим можно стереть коды неисправностей из памяти блока управления. Казалось бы, чего проще. Тем более что стирает сканер все коды, даже те, которые расшифровать не может. Кстати, самый часто задаваемый вопрос при выборе сканера такой: «А он может стирать ошибки?» Была бы функция стирания – остальное не важно! Тем более что до сих пор не перевелись «особо продвинутые» клиенты, которые просят стереть ошибки (или погасить лампочку Check Engine) и, подумать только, на полном серьезе платят за это деньги! Ну а если без шуток, применять режим $04 нужно вдумчиво и уж, конечно, не по всякому поводу. С одной стороны, существует целый ряд кодов неисправностей, наличие которых в памяти блока управления, просто блокирует активацию некоторых мониторов. То есть, если не провести ремонт и/или не стереть коды, эти мониторы не включатся и не завершатся никогда. С другой стороны, при выполнении процедуры стирания, вместе с кодами, из памяти блока управления исчезает кадр frezee frame, а также вся информация, накопленная при работе мониторов. Проще говоря, происходит обнуление и новая инициализация мониторов. А для того, чтобы все мониторы вновь обрели статус «завершенных», требуется провести достаточно сложный ездовой цикл, а иногда и не один. В общем, чтобы действительно профессионально пользоваться этой функцией, нужно хорошо знать устройство и работу системы управления двигателем. Впрочем, этот постулат в равной степени относится ко всем описываемым режимам, да и вообще к процессу диагностики в целом.
$05 (O 2 monitoring test results)
Вывод результатов мониторинга датчика кислорода. Этот режим можно смело занести в актив стандарта OBD II. Функции данного режима некоторые производители с удовольствием переняли и в том или ином виде используют в своих заводских протоколах. Выбрав этот режим, можно узнать о работе кислородного датчика (датчиков) если не все, то очень многое. Например, время переключения с низкого уровня на высокий и наоборот, максимальное, минимальное и среднее значение значения напряжения за период тестирования, заданные уровни напряжений перехода и т.п. Правда, такая информация недоступна для датчиков с линейной характеристикой (AFR-sensor), просто в силу того, что работают они совершенно по-другому. Само собой разумеется, что результаты теста будут доступны только в том случае, если данный монитор полностью отработал свой цикл, или, другими словами, монитор будет иметь статус «Завершен». Жаль только, что далеко не все производители выводят информацию в полном объеме. Пользуясь предоставленной им лазейкой, они предпочитают выводить результаты этого монитора в режиме $06, а это, как говорят в Одессе, «две большие разницы».
$06 (Monitoring test results for noncontinuously monitored systems)
Вывод результатов мониторинга для непостоянно тестируемых систем (или непостоянных мониторингов, как кому больше нравится). Подчеркнем, выводятся не статусы мониторов (см. режим $01), а именно результаты, это далеко не одно и то же! К этой группе относятся следующие мониторы: Монитор катализатора, Монитор системы поглощения топливных испарений, Монитор системы инжектирования вторичного воздуха, Монитор датчика (датчиков) кислорода, Монитор подогрева датчика (датчиков) кислорода, Монитор системы кондиционирования воздуха, Монитор системы рециркуляции ОГ. Совсем недавно к этому списку добавились мониторы термостата системы охлаждения и клапана системы вентиляции картера. Как следует из их определения, работают эти мониторы не всегда, а только тогда, когда выполняются определенные условия. Поэтому, для того чтобы все мониторы обрели статус «завершенных» требуется провести достаточно сложный ездовой цикл, а иногда и не один. Параметры ездовых циклов (читай требования к активации мониторов) различаются не только у разных производителей, но даже для разных моделей одной марки. Тем не менее существует диаграмма «типового» ездового цикла, проведение которого в большинстве случаев позволяет активировать если не все, то большинство мониторов. Опытный диагност в состоянии активировать и завершить все мониторы в течение 15-20 минутной поездки, длиной всего 3–5 километров. Но для этого нужно иметь под боком незагруженную трассу. Так что в крупных городах проведение такого рода тест-драйва может оказаться делом весьма затруднительным. А посему задачу по активации мониторов часто приходится решать владельцу автомобиля, в рамках его реальной эксплуатации. Это проще, но требует больше времени. Для ускорения процесса есть смысл проинформировать владельца о том, в каких режимах ему необходимо ездить, поскольку в противном случае, часть мониторов может просто не активироваться в течение многих недель и даже месяцев. Если нужно убедиться в правильности проведенного ремонта по факту наличия кода неисправности, есть смысл «погонять» автомобиль в режиме, зафиксированном в кадре Frezee Frame – это существенно сокращает время проверки. Вернемся к режиму $06. В целом на сегодняшний день он используется достаточно редко. Такая ситуация объясняется тем, что для интерпретации полученных результатов необходима документация производителя автомобиля. Чтобы объяснить, как именно пользоваться данным режимом, нужна еще одна журнальная статья, причем не самого маленького объема. Возможно, такая статья когда-нибудь и появится. Пока же ограничимся тем, что данные результаты производители выводят, используя специальные идентификаторы – TID и CID. Идентификатор TID соответствует определенному тесту, а идентификатор CID – определенному компоненту, подверженному процедуре тестирования. Даже если результаты теста вам непонятны, огорчаться не стоит. Все, что нужно, мониторы рано или поздно доведут до логического завершения: если в работе какой-либо из контролируемых систем существуют отклонения, в памяти контроллера обязательно появятся коды неисправностей, которые и надо рассматривать в качестве окончательных результатов. Следует обратить внимание на то, что количество реально задействованных мониторов очень сильно зависит от марки автомобиля, а также от рынка его сбыта. Автомобили, продаваемые на европейском рынке, в этом плане пока здорово отстают от аналогов, продаваемых за океаном. Еще более «кастрированы» автомобили, официально поставляемые в Россию.
$07 (Monitoring test results for continuously monitored systems)
Вывод результатов мониторинга для постоянно тестируемых систем. Здесь речь тоже идет о мониторах, но эти мониторы осуществляются непрерывно, т.е. сразу (или с определенной паузой) после пуска двигателя и до момента его остановки. Таких мониторов всего три: монитор компонентов (фактически дальнейшее развитие давно существующей системы самоконтроля входного и выходного интерфейса блока управления), монитор системы топливной коррекции / адаптации и монитор обнаружения пропусков воспламенения смеси. Очень важные и очень полезные мониторы, особенно последний из упомянутых. В отличие от сложной и запутанной формы выдачи информации, принятой в режиме $06, с этим режимом все намного проще. Результаты постоянных мониторов выводятся в виде привычных нам кодов неисправностей, но только в том случае, если эти коды зарегистрированы только в течение одного ездового цикла (или цикла прогрева). Поэтому такие коды называются «незавершенными», а сам режим $07 имеет альтернативное название – Read Pending DTC. Если в течение примерно 40–60 ездовых циклов код не подтверждается, он удаляется из памяти блока управления. Если же происходит повторная регистрация кода, он перестает быть «незавершенным» и переходит в разряд «сохраненных»; в этом случае этот код можно прочитать, используя режим $03.
$08 (Bidirectional controls)
Управление исполнительными компонентами. При активации данного режима сканер получает возможность прямого управления некоторыми исполнительными компонентами. Аналогичные функции поддерживаются практически всеми заводскими протоколами. Разница состоит в том, что в протоколе OBD II эта функция ориентирована прежде всего на исполнительные компоненты систем уменьшения токсичности, такие, как клапаны систем рециркуляции ОГ, продувки адсорбера и т.п. Сделано это для того, чтобы можно было оперативно проверить функционирование той или иной системы, не затрачивая время на тестовые поездки и мониторинг. Но такие проверки во многих случаях требуют наличия дополнительного оборудования и специальной информации. Поэтому пока режим $08 широкого распространения не получил. Возможно, ситуация изменится в лучшую сторону в ближайшие два-три года.
$09 (Vehicle information)
И, наконец, последний режим – вывод идентификационных параметров автомобиля. Такими параметрами являются VIN-код автомобиля, код калибровки, загруженной в ПЗУ, а также контрольная сумма этой калибровки. Вывод такой информации необходим по двум причинам. Во-первых, для оперативного отслеживания устаревших или проблемных версий программного обеспечения и замены их на более совершенные. Во-вторых, такая информация необходима для контроля на предмет возможного вмешательства в калибровки блока управления. Подсчет контрольной суммы осуществляется блоком каждый раз, после включения зажигания и занимает определенное время, поэтому торопиться не стоит. С выводом идентификационной информации производители пока не спешат. Даже на достаточно свежих автомобилях, поступающих с американского рынка, данная информация может поддерживаться не в полном объеме. Как уже говорилось, все описанные выше режимы должны поддерживаться сканером уровня GST. В принципе существующие на рынке сканеры в той или иной степени соответствуют данным требованиям. Однако во многих случаях производители сканеров используют для обозначения тех или иных режимов свои собственные названия. Кроме этого, они могут выводить отдельные функции за рамки конкретного режима и предлагать эти функции под отдельным пунктом меню. Так, например, часто можно увидеть в меню строку «Статус готовности мониторов». В стандартном протоколе OBD II / OBD этот пункт является просто одной из функций режима $01. Но многие производители сканеров считают, что проще и удобнее доступ к этой функции сделать в виде отдельного пункта меню. Недорогие модели сканеров OBD-II, а также многие универсальные сканеры, как правило, вообще не поддерживают режим $06. В одной статье невозможно рассмотреть все вопросы, связанные с практическим применением стандарта OBD II. Но очевидно, что данная система все больше будет проникать в практику сервиса. Недорогие сканеры уровня GST могут с успехом использоваться сразу на нескольких постах, например для входного и выходного контроля. Возможно, в недалеком будущем компактный GST – сканер станет чем-то вроде таких постоянных атрибутов диагноста, как электрический пробник или цифровой мультиметр. Использование OBD-протоколов во многих случаях может оказаться не только оправданным, но и весьма полезным. В первую очередь имеются в виду случаи, когда связь по заводскому протоколу по каким-либо причинам не может быть установлена, либо установлена некорректно. В этом случае использование протокола OBD II является единственно возможной альтернативой. Но даже в том случае, когда заводской протокол отрабатывается сканером абсолютно корректно, есть смысл дополнительно обратиться к блоку на языке OBD II. Практика показывает, что во многих случаях диагност может рассчитывать на получение дополнительной информации, недоступной в заводском протоколе. Диагностика, в сущности, является не чем иным, как процессом анализа информации. Чем шире и разностороннее собранная информация, тем больше вероятность принятия правильного решения. Это и есть главный результат.
Описание интерфейса универсального сканера ELM327.
Схема подключения сканера ELM327.
PID’ы Toyota/Lexus.
Протоколы стандарта OBD2
В рамках диагностического стандарта OBDII существует 5 основных протоколов обмена данными между электронным блоком управления (ЭБУ) и диагностическим сканером. Физически подключение автосканера к ЭБУ производится через разъем DLC (Diagnostic Link Connector), который соответствует стандарту SAE J1962 и имеет 16 контактов (2×8). Ниже представлена схема расположения контактов в разъеме DLC (рисунок 1), а также назначение каждого из них.
Рисунок 1 – Расположение контактов в разъеме DLC (Diagnostic Link Connector)
1. OEM (протокол производителя).
Коммутация +12в. при включении зажигания.
9. Линия CAN-Low, низкоскоростной шины CAN Lowspeed.
2. Шина + (Bus positive Line). SAE-J1850 PWM, SAE-1850 VPW.
10. Шина — (Bus negative Line). SAE-J1850 PWM, SAE −1850 VPW.
4. Заземление кузова.
5. Сигнальное заземление.
6. Линия CAN-High высокоскоростной шины CAN Highspeed (ISO 15765-4, SAE-J2284).
14. Линия CAN-Low высокоскоростной шины CAN Highspeed (ISO 15765-4, SAE-J2284).
7. K-Line (ISO 9141-2 и ISO 14230).
15. L-Line (ISO 9141-2 и ISO 14230).
16. Питание +12в от АКБ.
Назначение неопределенных контактов выбирается на усмотрение производителя автомобиля. Разъем должен быть расположен не далее, чем в 2 футах (0.61 метра) от рулевого колеса.
Иногда разъем OBD-II устанавливается на автомобили, которые в принципе не поддерживают ни один из OBD-II-протоколов. В таких случаях необходимо использовать специальный сканер, рассчитанный на работу с заводскими протоколами конкретной марки автомобиля — например, это касается Opel Vectra и некоторых автомобилей европейского рынка 1996-1997 гг.
Также бывают обратные ситуации, когда на автомобиле установлен нестандартный разъем, но при этом автомобиль поддерживает один из диагностических протоколов OBD-II.
Далее подробно рассмотрим формат и физический уровень каждого протокола связи в рамках стандарта OBDII.
SAE J1850 PWM
Существует два типа протокола J1850. PWM является высокоскоростным и обеспечивает передачу информации со скоростью 41,6 Кбайт/с. Он применяется в автомобилях марок Ford, Jaguar и Mazda. В протоколе PWM сигналы передаются по двум проводам, подсоединенным к 2 и 10 контакту диагностического разъема.
Формат сигнала протокола J1850 включает:
SOF — Start of Frame (начало кадра, высокий импульс на 200uS);
Header — заголовок длиной 1 байт;
CRC — Cyclic Redundancy Check (циклический избыточный код, 1 байт);
EOD — End Of Data (окончание данных, низкий импульс на 200uS).
Если рассматривать формат протокола более подробно по битам, то он примет следующий вид:
Реальный пример сигнала SAE J1850 выгладит следующим образом:
SAE J1850 VPW
Протокол VPW осуществляет передачу данных со скоростью 10,4 Кбайт/с, что существенно медленнее, чем у протокола PWM. Формат данного протокола идентичен SAE J1850 PWM . Данный протокол используется на автомобилях General Motors (GM) и Chrysler. VPW предусматривает обмен данными по одному проводу, подсоединенному ко 2 контакту диагностического разъема. Длина шины может достигать 35 метров.
ISO 9141-2
Данный протокол разработан компанией ISO. Он не такой сложный, как протоколы J1850 и не требует в использовании специальных коммуникационных микропроцессоров, но, с другой стороны, обеспечивает довольно медленную передачу данных со скоростью 10 Кбайт/c. Протоколы ISO 9141 и ISO 14230 схожи по физической реализации обмена информацией, но различаются ее использованием. Поэтому сканер ISO 9141, обычно может работать и с ISO 14230, но не наоборот.
В протоколе ISO 9141-2 сигналы передаются по 7 контакту (К-линия) и опционально по 15 контакту (L-линия). К-линия является двунаправленной (т.е. передает данные в обе стороны), L-линия однонаправленная и используется лишь для соединения ЭБУ и сканера, после чего линия L переходит в состояние логической единицы.
Физический уровень передачи информации в протоколах ISO 9141 и ISO 14230 заключается в одновременной передачи ЭБУ специального 8-битного кода по К- и L-линиям со скоростью 5Б/сек. Если код правильный, то ЭБУ посылает сканеру 8-битный код со скоростью последующего соединения. Затем передается еще два кода с информацией о последующем соединении и расположении К- и L-линий. Сканер возвращает отражение этих кодов в ЭБУ. На этом процесс распознавания окончен.
В общем виде процесс инициализации сигнала в протоколах ISO 9141 и ISO 14230 выглядит следующим образом:
Передача данных в протоколе осуществляется по следующей схеме:
ISO 14230-4 (др. название Keyword Protocol 2000)
На физическом уровне данный протокол идентичен ISO 9141, но является еще более медленным (скорость передачи данных от 1,2 до 10 Кбайт/c в быстрой версии).
ISO 15765 CAN
CAN-протокол был разработан компанией Bosch для автомобильного и промышленного применения. В рамках стандарта OBD2 протокол использует линии CAN High и CAN Low, т.е. 2 контакта для обмена сигналом: 6 и 14. Является самым скоростным и совершенным. Сейчас данный протокол используется на большинстве современных автомобилях. Стандарт CAN не регламентирует определенной скорости работы для каждой шины в автомобиле. С помощью отдельных и встроенных микроконтроллеров есть возможность менять ее от 20 Кбит/c до 1 Мбит/с. Более подробно CAN рассмотрен в статье CAN-шина и CAN-интерфейс.
Команда EmbeddedSystem занимается разработкой широкого спектра электронной продукции, включая разработку и производство электроники для автомобилей, автобусов и грузовиков. Возможна разработка и поставка электроники, как на коммерческих, так и на партнерских условиях. Звоните! Примеры проектов.