что такое obd в машине
Что такое диагностический разъем OBD
С 2006 года все автомобили, как легковые, так и грузовые вне зависимости от используемого топлива в обязательном порядке должны быть оснащены системой OBD. Это позволяет обслуживать автомобили и производить их ремонт на территории Евросоюза при условии наличия стандартизированного разъема OBD. При этом доступ к системам должен быть свободным для всех заинтересованных организаций и служб.
Обзор OBD
Как правило, в состав оборудования современных автомобилей входит электронный блок управления (ЭБУ). Это устройство предназначено для сбора и анализа данных о функционировании некоторых его систем. Чтобы предотвратить несанкционированное подключение к ЭБУ, можно выбрать один из трех способов:
установить дополнительный иммобилайзер с разрывом шины передачи данных;
установить любые дополнительные разъемы в разрыв шины передачи данных;
блокирование шины передачи данных OBD с помощью установки дополнительных каналов (должно происходить в режиме охраны сигнализации, которая установлена на ваше авто).
Общие понятия
Общий термин OBD означает самодиагностику автомобиля. Благодаря использованию этой технологии, появляется возможность контролировать различные системы автомобиля с помощью бортового компьютера.
В начале развития этой технологии имелась возможность получения информации о возникновении неисправности, однако, о ее причинах данные не поступали. В современных версиях в системе применяется стандартизированный цифровой интерфейс, благодаря которому имеется возможность получения получение данных о состоянии систем в реальном времени. При этом одновременно получаются коды неисправностей, идентифицирующих их.
Распиновка
Разъем OBD необходим для подключения приборов, с помощью которых контролируется функционирование систем автомобиля и определяют химический состав выхлопных газов. Под распиновкой OBD2 понимают определенные требования, которым подчиняются автопроизводители.
Место расположения диагностического разъема OBD должно располагаться на расстоянии максимум 18 см от рулевой колонки. Стандартизированная система характеризуется универсальностью и работает с использованием цифрового CAN-протокола, позволяющего получать детальную информацию о возникающих неисправностях.
Благодаря протоколам OBD2 становится возможно считывание параметров систем машины. Их число различается у разных автопроизводителей и зависит от ЭБУ.
Как правило, имеется возможность поддержки приблизительно 20 параметров. Для реализации контроля над какой-либо системой достаточно располагать 2-3 параметрами. В некоторых случаях их требуется больше. На количество параметров, контроль за которыми осуществляется одновременно, и форма их выдачи находится в зависимости от устройства, осуществляющего сканирование, и скорости передачи информации.
Устройство диагностического разъема OBD оснащено 16-ю контактами. Используя распиновку, происходит совмещение бортовых систем автомобиля с колодкой диагностики.
При обнаружении несоответствия состава выхлопных газов нормам, появляется надпись CheckEngine. Она говорит о том, что необходимо осуществить проверку двигателя.
БОРТОВАЯ СИСТЕМА ДИАГНОСТИКИ OBD II: ПРОШЛОЕ, НАСТОЯЩЕЕ, БУДУЩЕЕ (часть первая).
Честно стырено из интернета. Довольно занятная статья. Лично я для себя много нового узнал. надеюсь вам будет интересно — Много букв!
БОРТОВАЯ СИСТЕМА ДИАГНОСТИКИ OBD II: ПРОШЛОЕ, НАСТОЯЩЕЕ, БУДУЩЕЕ.
Адаптировано из статьи Ларри Карли для журнала «Underhood Service».
Эта технология сравнительно молодая и еще не получила широкого распространения на рынке запчастей, но это лишь вопрос времени. Речь идет о системе OBD II — санкционированной государством бортовой системе диагностики для контроля качества выхлопа. Все легковые и легкие грузовые автомобили с 1996 года выпуска оборудованы этой системой, хотя впервые она стала использоваться в 1994 году лишь на некоторых моделях.
OBDII отличается от всех остальных систем самодиагностики тем, что предназначена исключительно для проверки качества выхлопа.
Другими словами, она зажигает индикатор неисправности MIL, как только количество углеводорода (HC), оксида углерода (CO), оксидов азота (NOX) или паров топлива в отработавших газах превышает в 1,5 раза федеральные стандарты токсичности автомобилей. Это может быть следствием ряда причин: повышение концентрации углеводорода в выхлопе из-за случайных пропусков зажигания; падение кпд каталитического нейтрализатора ниже определенного порога; попадание воздуха в герметичную топливную систему; повышение концентрации в выхлопе оксидов азота из-за ошибки в системе рециркуляции отработавших газов; неисправность важного датчика или другого устройства для снижения токсичности выхлопа.
То есть индикатор неисправности может загораться даже тогда, когда автомобиль на первый взгляд работает нормально и нет проблем с управляемостью.
Индикатор неисправности MIL в автомобилях, оборудованных системой OBD II, предназначен для того, чтобы предупреждать автомобилистов о повышении токсичности отработавших газов и дать им возможность решить эту проблему. Однако мы все хорошо знаем, что большинство автолюбителей отлично умеют игнорировать предупредительные сигналы, даже если из-под капота дым столбом и двигатель издает страшные звуки. Вот поэтому планируется включить систему OBD II во все существующие программы контроля выхлопных газов. Если индикатор MIL горит во время тестирования, значит, автомобиль не выдерживает проверку, даже если токсичность выхлопа в пределах нормы.
Проблема большинства программ инспекции транспортных средств в том, что они были разработаны в далеких 1980-ых для выявления сильных источников загрязнения окружающей среды. Такое тесты были введены главным образом для измерения токсичности карбюраторных двигателей на холостом ходу (они являются самыми токсичными на холостом ходу) и проверяли на наличие только двух загрязняющих веществ – несгоревших углеводородов (HC) и оксида углерода (CO). Значения максимально допустимых концентраций вредных веществ, установленные для различных моделей, были довольно высокими, поэтому большинство автомобилей выдерживало проверку.
Если и были попытки повысить уровень инспекции до нового стандарта I/M 240, то отсутствие народной и политической поддержки мешало реализовать эту идею. Стандарт I/M 240 требует проведодить проверку состава отработавших газов в режиме нагрузки с помощью динамометра, во время езды на разных скоростях и по заранее спланированному маршруту. В таком случае выхлопные газы проверяются не только на общую концентрацию углеводорода (HC) и оксида углерода (CO) (в граммах, а не в процентах), но также и на содержание оксидов азота (NOX). По общему количеству выбросов за ездовой цикл, длящийся 240 секунд, вычисляется средний суммарный балл, который и определяет, прошел автомобиль проверку или нет. В тестирование также включены: проверка интенсивности выделения паров топлива для измерения скорости потока паров топлива через клапан продувки фильтра и проверка давлением системы улавливания паров топлива при выключенном двигателе для выявления утечек в топливном баке, топливопроводе или топливной крышке.
Изначально программа контроля I/M 240 была предназначена для тех районов страны (США), которые не отвечают национальному стандарту качества окружающего воздуха. Однако после того, как программа провалилась в штате Мэн, многие штаты от нее отказались. Из-за своей дороговизны и сложности, а также отсутствия поддержки общественности, программа I/M 240 была обречена на неудачу с самого начала. Поэтому в большинстве штатов сейчас используется простая диагностика OBD II для проверки легковых и грузовых автомобилей с 1996 года выпуска на соблюдение норм токсичности отработавших газов.
КОРОТКАЯ ИСТОРИЯ С ДАЛЕКО ИДУЩИМИ ПОСЛЕДСТВИЯМИ
История создания OBDII берет начало в 1982 году в Калифорнии, когда Калифорнийский совет по ресурсам атмосферы начал разрабатывать нормативы, согласно которым все автомобили, проданные в этом штате начиная с 1988 года, должны быть оборудованы бортовой системой диагностики для обнаружения неисправностей. Первая бортовая система диагностики (которая стала известна как OBDI) была относительно простой и контролировала только кислородный датчик, систему рециркуляции отработавших газов, топливную систему и блок управления.
Создание OBD I было шагом в верном направлении, но ей не хватало требований к стандартизации для различных марок и моделей. Для разных моделей требовались разные адаптеры, а с некоторыми системами можно было работать только с помощью дорогостоящих дилерских сканеров. Поэтому, когда Калифорнийский совет по ресурсам атмосферы начал разрабатывать стандарты для системы OBD II, приоритетной задачей была стандартизация: стандартный 16-контактный диагностический разъем (DLC), в котором у каждого контакта свое назначение, стандартные электронные протоколы, стандартные диагностические коды неисправностей и стандартная терминология.
Еще один недостаток системы OBD I был в том, что она не могла обнаружить определенные проблемы, например, неисправность каталитического нейтрализатора или его отсутствие, а также пропуски воспламенения или проблемы с выделением паров топлива. Более того, индикатор неисправности загорался только после того, как ошибка уже произошла, но не было возможности регистрировать процесс ухудшения состояния компонентов выхлопной системы. Таким образом, появилась необходимость создать более сложную, усовершенствованную систему.
Со временем Калифорнийский совет по ресурсам атмосферы разработал стандарты для бортовой системы диагностики следующего поколения, которая вошла в употребление в 1989 году и стала известна как OBD II. Поэтапное внедрение новых стандартов началось в 1994 году, и к 1996 году все модели, выпущенные в Калифорнии, были оборудованы системой OBD II.
Аналогичные стандарты были введены федеральным Законом о чистом воздухе от 1990 года, согласно которому транспортные средства всех 49 штатов должны были быть оборудованы системой OBD II к 1996 году. Однако в законе была оговорка: система OBD II должна быть полнофункциональной только после 1999 года. Поэтому в некоторых системах OBD II 1996 года не поддерживается возможность тестирования системы выделения топливных паров.
ПЕРВЫЕ МОДЕЛИ, ОБОРУДОВАННЫЕ СИСТЕМОЙ OBD II
Модели 1994 года, оборудованные системой OBD II: Buick Regal 3800 V6, Corvette, Lexus ES3000, Toyota Camry (1MZ-FE 3.0L V6) и пикап T100 (3RZ-FE 2.7L 4), Ford Thunderbird & Cougar 4.6L V8, и Mustang 3.8L V6.
Модели 1995 года, оборудованные системой OBD II: Chevy/GMC S, пикапы серии T, Blazer и Jimmy 4.3L V6, Ford Contour & Mercury Mystique 2.0L 4 & 2.6L V6, Chrysler Neon, Cirrus и Dodge Stratus, Eagle Talon 2.0L DOHC (без турбонаддува), и Nissan Maxima и 240 SX.
В вышеперечисленных моделях не обязательно используются все функции системы OBD II, но поддерживаются основные диагностические возможности.
ОБНОВЛЕНИЕ АППАРАТНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМЫ OBD II
Не думайте, что OBD II – это только более продвинутая версия программ самодиагностики. Она подразумевает гораздо больше.
Обычно автомобили, поддерживающие систему OBD II, имеют:
• В два раза больше кислородных датчиков, чем в автомобилях без поддержки OBD II (большинство из которых – кислородные датчики с подогревом). На выходе каталитического нейтрализатора есть дополнительные кислородные датчики.
• Более мощный Блок Управления Трансмиссией с 16-разрядными (Chrysler) или 32-разрядными (Ford & GM) процессорами для обработки более 15000 новых калибровочных констант, добавленных OBD II.
• Электронно-стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ) микросхемы, позволяющие перепрограммировать ЭБУ согласно с исправленным или обновлённым ПО посредством канала передачи данных или внешнего компьютера.
• Модифицированная система улавливания паров топлива (EVAP) с возможностью проверки системы очистки или усовершенствованная система EVAP с электромагнитным клапаном вентиляции, датчиком давления в топливном баке и соединительные устройства,
• Линейный клапан рециркуляции отработавших газов с электронным управлением, датчик положения плунжера.
• Последовательный впрыск топлива вместо многоточечного или центрального впрыска.
• датчик абсолютного давления в коллекторе для контроля нагрузки на двигатель и датчик расхода воздуха для контроля воздушного потока
АВТОСКАНЕРЫ ДЛЯ OBD II
Для работы с автомобилем, оборудованным OBD II необходимо иметь автосканер, совместимый с этой системой. Многие сканеры, которые были изготовлены до 1996 года, не подходят для работы с OBD II и смена картриджа тут не поможет. Вам понадобится аппаратный адаптер для старого сканера или новый сканер, совместимый с OBD II.
На дилерских сервисных станциях корпорации GM для диагностики автомобилей с 1996 года выпуска этой марки используется сканер Tech 2. Функции сканера Tech 2: вывод до 9-ти текущих параметров системы одновременно, вывод стоп-кадров для 5-ти параметров, отображение гистограмм и линейных графиков, захват текущих данных и способность хранить 2 стоп-кадра данных. Подобным образом, для диагностики автомобилей Chrysler используется сканер DRB III, а для моделей Ford с 1996 года выпуска – Дилерский системный сканер Ford VCM
ЭТОТ ПРОТИВНЫЙ ИНДИКАТОР MIL
Все знакомы с индикаторной лампой неисправности «Check Engine», или ее более поздним аналогом «Malfunction Indicator Lamp» (MIL) в автомобилях, оборудованных системой OBD II. Часто кажется, что индикатор MIL живет своей жизнью.
Работники нескольких автопарков компании General Motors столкнулись с проблемой: в автомобилях GM с 1996 года выпуска с платформами J-, N- и H-body индикатор MIL загорался из-за того, что автомобилисты и работники автопарка использовали неправильную процедуру дозаправки топливного бака. В системе улавливания паров топлива этих моделей OBD II использует вакуум для обнаружения утечек воздуха. Если крышка топливного бака сидит неплотно, а также, если во время включения зажигания или холостого хода бензобак заполнен, может возникнуть ложный код ошибки P0440, вследствие чего загорится лампа MIL. Специалисты компании GM советуют дилерам и клиентам перепрошить ЭСППЗУ и с помощью обновленной версии во время езды проверить систему улавливания топливных паров.
Причиной ложных сигналов также может оказаться некачественное топливо. В таком случае генерируется код P0300, означающий случайные пропуски зажигания из-за обедненной топливной смеси, причиной чего может быть утечка вакуума, низкое топливное давление, засоренные форсунки и т.д., а также из-за таких проблем в системе зажигания, как грязные свечи зажигания, плохая проводка, слабая катушка и т.п. Система самодиагностики OBD II отслеживает пропуски зажигания в отдельных цилиндрах, при этом интенсивность пропусков не более 2 % считается нормой. Попадание воды в топливо или различные комплексы присадок в топливе улучшенного состава могут увеличить количество пропусков зажигания и сгенерировать код ошибки.
Для сведения к минимуму ложных сигналов система OBD II запрограммирована таким образом, чтобы индикатор MIL загорался только при повторном возникновении неисправности в определенных условиях. В случае других неисправностей (которые обычно приводят к резкому и значительному повышению токсичности выбросов) индикатор MIL загорается сразу (то есть при первом же возникновении ошибки). Поэтому для корректной диагностики необходимо знать, с каким типом кодов вы имеете дело.
Диагностические коды неисправностей типа А – самые опасные. При возникновении такого рода неисправности сразу же загорается индикатор MIL, и система OBD II сохраняет в памяти предысторию неисправности, запись и стоп-кадры данных о неисправности.
Коды неисправностей типа В говорят о менее серьезных проблемах выхлопной системы, в этом случае лампа MIL включается при обнаружении неисправности в двух поездках подряд, но если ошибка случается только один раз, код не генерируется. Если это все-таки случается и загорается индикатор MIL, то предыстория неисправности, запись и стоп-кадры данных о неисправности сохраняются там же, где и коды типа А.
Между прочим, ездовой цикл, помимо включения-выключения зажигания, включает в себя еще и цикл нагрева двигателя. Это значит, что для совершения ездового цикла надо запустить двигатель и «гонять» двигатель до тех пор, пока температура охлаждающей жидкости не поднимется до 40° по Фаренгейту (если температура при запуске двигателя меньше 160° по Фаренгейту)
При кодах типа А или В индикатор MIL горит до тех пор, пока неисправный элемент не пройдет самотестирование в течение трех ездовых циклов. А если дело в случайных пропусках зажигания (код P0300) или проблема с топливным балансом, то индикатор не погаснет до тех пор, пока система не пройдет самотестирование в тех же рабочих условиях, при которых появилась неисправность (не более 375 об/мин и 10 %-ной нагрузки). Даже если стереть код ошибки с помощью сканера или отключить питание блока управления, индикатор MIL все равно будет продолжать загораться, пока проблема не будет устранена окончательно.
Аналогично, если преднамеренно отсоединить датчик, индикатор MIL не обязательно будет загораться – это зависит от приоритетности датчика (как он влияет на качество выхлопа) и от того, сколько ездовых циклов понадобится для того, чтобы система OBD II обнаружила ошибку и сгенерировала соответствующий код.
Коды типов C и D не относятся к выхлопной системе. При возникновении кодов типа C индикатор MIL (или другая предупредительная сигнальная лампа) может загореться, но при кодах типа D – нет.
ЕЗДОВОЙ ЦИКЛ OBD II
Предположим, все проблемы выхлопной системы автомобиля устранены. Проверить исправность работы автомобиля можно, совершив ездовой цикл.
Цель ездового цикла OBD II – выполнить условия, необходимые для запуска бортовой диагностики. Ездовые циклы должны выполняться после того, как из памяти блока управления стерты все коды ошибок или отключена батарея. В процессе ездового цикла активируются все системные мониторы, позволяющие выявлять последующие неисправности.
Ездовой цикл OBD II начинается с запуска двигателя из холодного состояния (температура охлаждающей жидкости меньше 122° по Фаренгейту, разница температур охлаждающей жидкости и воздуха – не более 11 градусов)
ПРИМЕЧАНИЕ: ключ зажигания лучше поворачивать после холодного запуска двигателя, иначе кислородный датчик с подогревом может не заработать.
1. После холодного запуска подержите двигатель его на холостых оборотах 2,5 минуты с включенным кондиционером и обогревом заднего стекла. В это время система OBD II проверяет цепи подогревателя кислородного датчика, воздушный насос и систему улавливания паров топлива.
2. Выключите кондиционер и обогрев заднего стекла; разгоните автомобиль до 55 миль в час при полуоткрытой дроссельной заслонке. OBD II проверяет систему зажигания, регулирование состава горючей смеси и продувку угольного фильтра.
3. Держите скорость 55 миль в час в течение трех минут. OBD II проверяет систему рециркуляции отработавших газов, воздушный насос, кислородные датчики и продувку угольного фильтра.
4. Сбросьте скорость (в режиме свободного выбега) до 20 миль в час, не давя на тормоз и не выжимая сцепление. OBD II проверяет систему рециркуляции отработавших газов и продувку угольного фильтра.
5. Вновь разгоните автомобиль до 55 – 60 миль в час при полуоткрытой дроссельной заслонке. OBD II снова проверяет систему зажигания, регулирование состава горючей смеси и продувку угольного фильтра.
6. Держите скорость 55 – 60 миль в час в течение пяти минут. OBD II проверяет кпд каталитического нейтрализатора, систему зажигания, регулирование состава горючей смеси, систему рециркуляции отработавших газов, кислородные датчики и продувку угольного фильтра.
7. Сбросьте скорость (в режиме свободного выбега) до 20 миль в час, не давя на тормоз. OBD II осуществляет окончательную проверку системы рециркуляции отработавших газов и продувки угольного фильтра.
OBD: ПРОГНОЗ НА БУДУЩЕЕ
OBD II – очень сложная и действенная система диагностики проблем выхлопной системы. Однако, когда возникает необходимость решать эти проблемы, в руках автолюбителя эта система становится не более эффективной, чем OBD I. Ведь большинство из нас так и не потрудятся в ней разобраться, если только не ввести какие-нибудь обязательные правила, например, всегда проверять индикатор MIL во время проверки на токсичность отработавших газов.
В настоящее время планируется разработать систему OBD III – более усовершенствованную версию OBD II благодаря применению телеметрии. При помощи миниатюрного ретранслятора, аналогичного тому, что используется в системе автоматического сбора пошлины, система OBD III сможет сообщать о неисправностях напрямую в соответствующий контрольный орган. Ретранслятор будет передавать идентификационный номер автомобиля (VIN-код) и диагностический код ошибки. Система может быть настроена на то, чтобы автоматически сообщать о проблемах выхлопной системы через сотовую или спутниковую линию связи в тот момент, когда загорается индикатор MIL, или отвечать на сотовый, спутниковый или придорожный сигнал запроса о текущем состоянии выхлопной системы.
Чем этот подход так привлекателен для регулирующих органов, так это своей эффективностью и экономичностью. С существующей системой все транспортные средства области или штата (США) раз в год или в два должны проходить проверку на токсичность отработанных газов, в результате которой обнаруживается около 30 % автомобилей с проблемами выхлопной системы. С появлением дистанционного контроля автомобилей при помощи бортовой телеметрии исчезнет необходимость периодических осмотров, так как проверяться будут только автомобили, приславшие отчеты о неисправностях. На самом деле, подобная система – OnStar – уже есть в моделях General Motors 2004, 2005 и 2006 года выпуска. OnStar контролирует систему OBD II и информирует водителя об обнаруженных неисправностях. Благодаря заблаговременному выявлению неисправностей корпорация General Motors имеет возможность сэкономить на ремонтных расходах (и прилично сократить затраты на гарантийное обслуживание).
С одной стороны, OBD III с ее телеметрической аппаратурой, сообщающей о неисправностях, избавит потребителей от неудобной и дорогостоящей необходимости планового техосмотра их автомобилей. До тех пор, пока не будет отправлен отчет о неисправности, тестирование проходить не обязательно. С другой стороны, когда обнаружена повышенная токсичность выхлопных газов, автомобилист обязан устранить эту проблему, что и является целью всех программ контроля над загрязнением воздуха. Если сосредоточить внимание на транспортных средствах, которые являются действительно серьезными источниками загрязнения, можно существенно улучшить состояние окружающей среды. Однако сейчас такие источники загрязнения могут избегать проверок и ремонтов в течение двух лет (в тех областях, где плановый техосмотр проводится раз в два года). А в областях, где программы техосмотра вообще не проводятся, и вовсе нет никакой возможности обнаружить такие автомобили. Внедрение системы OBD III изменит эту ситуацию.
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 = <'P', 'C', 'B', 'U'>;
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 > 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
На данном этапе мы разобрались в том, каким образом организовать диалог с адаптером, посылать ему команды, получать и расшифровывать его ответы. Это большая часть работы, если считать то, сколько времени уходит на изучение материала, но в то же время довольно таки интересная. За пределами этой статьи осталось множество проблем связанных с визуальным интерфейсом, а также множество дополнительных функций, таких как добавление новых пидов из файла, стандартный и расширенный способ подключения к адаптеру и построения графиков.