Чтение кодов ошибок автомобиля

Изначально необходимо пояснить что для подключения к авто будет использоваться 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, что говорит о том, что у вас не получится подключиться к автомобилям, которые используют эти протоколы.

Подключение

Подключение к адаптеру происходит в несколько этапов:

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 не удалось, тогда адаптер начинает автоматический подбор протокола.

Исходя из описанных выше команд, формируем инициализационную строку.

Желательно давать возможность пользователю сменять инициализационные команды, потому как для того чтобы подобрать «ключ» к некоторым авто необходимо выбрать более подходящие настройки адаптера. В нашем же случае используются настройки, которые походят для большинства стандартных протоколов.

Так же желательно обратить внимание на команду 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]

Я продемонстрирую как определить какие датчики присутствуют в автомобиле при помощи одного из пидов. Например:

Используя следующую табличку можем определить какие пиды поддерживаются нашим автомобилем, начиная от 01 до 20:

Исходя из получившихся данных можем определить, что наш автомобиль поддерживает следующие пиды:

Теперь вместо отправки всех 32 команд и ожидания ответа на них, несмотря на то, что некоторые могут отсутствовать, мы будем использовать всего 15 команд. Но и это не предел так называемой оптимизации. Для того чтобы данные обновлялись еще быстрее советую запрашивать только данные о тех датчиках, которые отображаются на экране. Хотя это ограничивает некоторый функционал приложения. Например, запись истории.

Считывание и расшифровка ошибок автомобиля

Ошибки автомобиля тоже могут быть различными и для них тоже существуют отдельные команды. Например:

А теперь пояснение.

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

3, 4, 5 символы формируются по этой таблице:

Исходя из этого можем попробовать разобрать следующий ответ 0001000000111110

Эпилог

На данном этапе мы разобрались в том, каким образом организовать диалог с адаптером, посылать ему команды, получать и расшифровывать его ответы. Это большая часть работы, если считать то, сколько времени уходит на изучение материала, но в то же время довольно таки интересная. За пределами этой статьи осталось множество проблем связанных с визуальным интерфейсом, а также множество дополнительных функций, таких как добавление новых пидов из файла, стандартный и расширенный способ подключения к адаптеру и построения графиков.

Нюансы расшифровки кодов диагностических ошибок OBD-2

Изобретение транзисторов и миниатюризация их элементной базы не могли не быть замеченными автомобилестроителями. Вместо полностью аналоговых, страдающих невысокой точностью и привередливых механических датчиков появились цифровые и комбинированные. Это в целом положительно сказалось как на надёжности измерения параметров работы силового агрегата, так и на увеличении его ресурса.

История появлении кодов ошибок OBD-II

А вскоре появились и электронные блоки управления, первое поколение которых отвечало за централизованную интерпретацию всех данных, поступающих от датчиков и отображение их показаний на панели приборов. Постепенно ЭБУ начали оснащаться функцией обратной связи, что позволило, кроме чисто считывающих задач, выполнять и контролирующие, частично взяв управление некоторыми функциями работы автомобиля на себя. Блок управления стал настолько умным, что уже умел распознавать сбои в работе датчиков и других блоков автомобиля (прежде всего – отвечающих за работоспособность силового агрегата) и записывать их во флеш-память, чтобы эти ошибки позже можно было интерпретировать. Для этого использовались специальные устройства, которые подключаются к ЭБУ и одновременно к компьютеру (ноутбуку, планшету, а сегодня – и к смартфону). Проблема была в том, что каждый автопроизводитель разрабатывал блоки управления, которые использовали собственную систему кодировки. Более того, зачастую даже в пределах одной марки разные версии ЭБУ не понимали друг друга. Это создавало огромные сложности при диагностировании неисправностей автомобилей для сервисных центров.

Решение пришло с неожиданной стороны. Начиная с середины 80-х годов, прогрессивная мировая общественность начала бить в колокола, утверждая, что агрессивная технологическая деятельность человеческой цивилизации, прежде всего стран с развитой экономикой, привела к потеплению климата. И виноватыми в этом оказались выбросы парниковых газов, источником которых были и автомобили. Внимая гласу учёных, правительство США предприняло некоторые практические шаги, направленные на улучшение экологической ситуации. Одной из таких мер стало принятие стандартов, касающихся оснащения автомобилей с целью уменьшения вреда, наносимого системой выхлопа. В частности, в 1996 году внедрение автомобилестроителями в состав автомобилей блоков ЭБУ стало обязательным, при этом эти устройства должны были, прежде всего, контролировать те параметры работы силового агрегата, которые имели прямое или опосредованное отношение к качеству выхлопа.

Стандарт также упорядочивал структуру обмена информацией между датчиками и исполнительными устройствами с одной стороны, и ЭБУ с другой. Так появилась система OBD-II, регламентирующая порядок записи и считывания информации о работе двигателя. И хотя вначале стандарт имел достаточно узкую направленность и не позволял диагностировать большой спектр других узлов и систем автомобиля, он стал необычайно популярным и начал приобретать сторонников и за пределами США. Этому способствовал и тот факт, что действие стандарта распространялось на все автомобили, производимые на территории Соединённых Штатов, включая иностранные бренды, производимые на местных мощностях для местного же рынка.

В том же 1996 году стандарт был взят на вооружение некоторыми европейскими и азиатскими автопроизводителями, но массовый переход на использование стандартизированного протокола ОБД-2 в отношении кодов ошибок произошла в 2001 году. Правда, касалось это только ТС, оснащённых бензиновым мотором. Для авто с дизельным двигателем переход на использование протокола произошёл на три года позже, в 2004 году. В частности, на территории России стандарт OBD-II внедрён на следующих предприятиях:

Несмотря на появление стандартизированного протокола, в настоящее время существует несколько его реализаций, привязанных к тем или иным экологическим стандартам:

Режимы диагностики

Использование протокола OBD-II позволяет выполнять, кроме собственно диагностики неисправностей, целый ряд других функций, которые можно сгруппировать в соответствии со следующими режимами:

Стоит немного подробнее описать первый режим, который поддерживает запись порядка 20 различных параметров. Однако в некоторых реализациях режима, поддерживаемых отдельными производителями, список контролируемых параметров намного больше, доходя до порядка сотни позиций. В числе основных параметров, отслеживаемых диагностической системой ОБД-2, можно отметить следующие:

Интерпретация данных, контролируемых ЭБУ при работающем двигателе, в большинстве случаев требует одновременного отслеживания небольшого количества характеристик (двух – трёх), но в некоторых случаях может потребоваться просмотр и большего числа параметров. Но эта возможность обеспечивается не всегда, поскольку она зависит, во-первых, от конкретной модели сканера, а во-вторых, от скорости обмена данными между сканером и ЭБУ, которая частично зависит и от используемого протокола. Влияет на это и то, в каком формате передаются данные – текстовом, цифровом или графическом. На сегодня самым распространённым протоколом является ISO-9141, однако, он же считается и одним из самых медленных, не позволяющих обеспечить просмотр более 4 параметров с приемлемой для правильной интерпретации результатов частотой.

Расшифровка ошибок системы ОБД-2 на русском языке

Несмотря на стандартизацию протокола, в конкретных реализациях как ЭБУ, так и сканеров могут присутствовать некоторые разночтения, связанные с особенностями конструкции конкретной марки и модели автомобиля. Как правило, в сервисных центрах используют многофункциональные автосканеры, оснащённые большим количеством разъёмов и переходников, что позволяет производить диагностику подавляющего числа автомобилей вне зависимости от модели. Стандартизация диагностического разъёма упростила чтение ошибочных кодов. Более того, рядовому автолюбителю достаточно заполучить сканер, чтобы иметь возможность самостоятельно определять состояние всех систем своего автомобиля, получая всю информацию в графическом или буквенно-числовом виде на мониторе ноутбука или стационарного ПК. Но при наличии неисправностей система выдаёт код, который необходимо расшифровать. Документация к транспортному средству не всегда содержит описание таких ошибок, но даже если оно присутствует, то зачастую на английском языке. Поэтому расшифровку кодов ошибок OBD-2 на русском языке следует ещё поискать – обычно такая информация берётся из Всемирной сети. Собственно код представляет собой комбинацию из одной литеры и четырёх символов.

Первый символ принимает следующие значения:

На месте второго символа стоит цифра, принимающая значение 0 или 1. Нолик обозначает, что это код из категории базовых, разработанный специалистами SAE (Ассоциация инженеров автомобилестроительной отрасли). Этот код является общим для всех автомобилей, ЭБУ которых поддерживают протокол ОБД-2 кодов неисправностей. Если указана единичка, это указывает на расширенный код неисправности, который обычно устанавливают автопроизводители для тех моделей, для которых стандартных описаний неисправностей недостаточно. Так что если сканер выводит именно такую ошибку, расшифровать её по стандартной таблице, скорее всего, не удастся (есть исключения – например, сканер Hellion, в память которого заложена очень обширная информация о расширенных кодах ошибок).

Третья цифра конкретизирует место возникновения неисправности (многие специалисты полагают, что буквенное обозначение является в определённой мере дублирующим, то есть лишним):

Наконец, 4 и 5 символы – это цифра, обозначающая порядковый номер ошибки соответствующего класса или категории.

Предлагаем вашему вниманию подробную расшифровку кодов ошибок ОБД-2 (с переводом на русский язык).