автомобиля obd can bus на АлиЭкспресс — купить онлайн по выгодной цене

Что такое obdii/eobd?

1) Бортовая диагностика (OBD) II Первое поколение бортовой диагностики (OBDI) было разработано Калифорнийским комитетом по воздушным ресурсам (ARB) и внедрено в 1988 году для слежения за системой контроля выпуска газов автомобиля.

С развитием технологии было разработано новое бортовой диагностики (OBDII).

Система OBDIIпредназначается для слежения за элементами контроля выбросов и ключевыми компонентами двигателя путем выполнения постоянных или периодических тестов определенных компонентов и состояний автомобиля.

При обнаружении неисправности OBDIIвключает индикатор (MIL) на приборной панели автомобиля. Система собирает информацию о выявленных неисправностях, что помогает специалисту безошибочно определить и устранить проблему. Далее

перечислены три составные части подобной информации:  

2) Коды неисправностей (DTC) DTC – коды, записывающиеся в компьютер бортовой диагностической системы при обнаружении неисправности. Эти коды определяют проблемные зоны и предназначаются для предоставления информации о местоположении возможной проблемы.

DTC – пятизначный код, состоящий из букв и цифр. Первый символ (буква) определяет, какая часть системы задает код. Остальные четыре символа (цифры) предоставляют дополнительную информацию о происхождении DTC и об эксплуатационных условиях вызвавших неполадку.3)

Местоположение диагностического разъема (DLC) DLC (диагностический разъем) – стандартный 16-контактный разъем, соединяющий бортовой компьютер с прибором для считывания кодов. У большинства автомобилей DLC обычно расположен под приборной панелью на 30 см от центра.

В некоторых азиатских и европейских автомобилях разъем находится за пепельницей, то есть для доступа к разъему пепельница должна быть извлечена. Если DLC находится в другом месте, об этом должно быть сказано в описании автомобиля.

4) Датчики готовности OBDII

Важная часть OBDII системы – датчики готовности, которые определяют, все ли компоненты системы были протестированы системой OBD. Они запускают циклические тесты для систем и отдельных узлов, чтобы убедиться, что они работают в допустимых пределах. В настоящее время существуют 11 датчиков готовности OBDII утвержденных Американским Природоохранным Агентством (EPA).

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

Некоторые детали и системы автомобиля постоянно проверяются системой OBDII, ниже приведен список таких систем:

Пока автомобиль находится в рабочем состоянии, система OBDII постоянно проверяет перечисленные компоненты.

5) Определения OBDII Совмещенный моторно-трансмиссионный компьютер (PCM) – электронный блок управления двигателем. На некоторых автомобилях может быть совмещен с блоком управления коробкой передач. Индикатор неисправности (MIL) – лампа на приборной панели, оповещающая водителя при неисправностях в системах автомобиля.

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

DTC – коды диагностики отказов (коды неисправностей), показывающие, какая из частей системы автомобиля повреждена. EnablingCriteria – условия, которые должны быть выполнены перед установкой или выключением датчиков. Некоторые датчики требуют выполнения определенного ездового цикла для включения.

Эти циклы отличаются в зависимости от датчиков и автомобиля. Ездовой цикл OBDII – выполнить условия, необходимые для запуска автомобилем бортовой диагностики. Некоторые ездовые циклы должны выполняться при стертых DTC или при отключенной батарее. Ездовой цикл зависит от автомобиля и датчика, который нуждается в перегрузке.

FreezeFrameData – Когда появляются неполадки, OBDII не только запоминает код, но и делает снимок рабочих параметров для облегчения определения проблемы. Полученные значения называются FreezeFrameData. Они могут включать в себя важные параметры двигателя, такие как число оборотов, скорость автомобиля, воздушный поток, нагрузка на двигатель, давление топлива, значение коррекции топливоподачи, температуры охлаждающей жидкости, опережение зажигания. Коррекция топливоподачи (FT) – функция системы управления двигателем по корректировке

топливовоздушной смеси с целью достижения ее оптимального содержания.

Что такое система диагностики автомобилей obd ii – автосканеры.ру

История диагностики с OBD II начинается в 50-х гг. прошлого века, когда правительство США вдруг обнаружило, что поддерживаемое им автомобилестроение в конечном счете ухудшает экологию. Вначале они не знали, что с этим делать, а затем стали создавать различные комитеты для оценки ситуации, годы работы которых и многочисленные оценки привели к появлению законодательных актов. Производители, изображая, что подчиняются этим актам, на самом деле не выполняли их, пренебрегая необходимыми тестовыми процедурами и стандартами. В начале 70-х законодатели предприняли новое наступление, и опять их усилия были проигнорированы.

И только в 1977 г. ситуация начала меняться. Наступил энергетический кризис и спад производства, и это потребовало от производителей решительных действий по спасению самих себя. Департамент по контролю за воздушной средой (Air Resources Board, ARB) и Агентство по защите окружающей среды (Environment Protection Agency, EPA) пришлось воспринимать всерьёз.


На этом фоне и развивалась концепция диагностики OBD II. В прошлом каждый производитель использовал собственные системы и способы контроля выбросов. Чтобы изменить такое положение, Ассоциация автомобильных инженеров (Society of Automotive Engineers, SAE), предложила несколько стандартов. Можно считать, что рождение OBD произошло в тот момент, когда ARB сделало обязательными многие стандарты SAE в Калифорнии для автомобилей начиная с 1988 г. выпуска.

Первоначально система диагностики OBD IIбыла совсем не сложной. Она относилась к датчику кислорода, системе рециркуляции выхлопного газа (EGR), системе подачи топлива и блоку управления двигателем (ECM) в той части, которая касается превышения норм для выхлопных газов. Система не требовала единообразия от производителей. Каждый из них реализовывал собственную процедуру контроля выхлопов и диагностики. Системы мониторинга выхлопов не были эффективными, поскольку их создали как дополнение к автомобилям, уже находящимся в производстве. Автомобили, исходная конструкция которых не предусматривала мониторинга выхлопных газов, часто не удовлетворяли принятым нормативам. Производители таких автомобилей делали то, что требовали ARB и EPA, но не более. Поставим себя на место независимого автосервиса. Тогда нам пришлось бы иметь уникальный диагностический прибор, описания кодов и инструкции по ремонту для автомобилей каждого производителя. В таком случае автомобиль невозможно было бы хорошо отремонтировать, если вообще удалось бы справиться с ремонтом.


Правительство США оказалось в осаде со всех сторон, начиная с автосервисов и заканчивая защитниками чистого воздуха. Все требовали вмешательства EPA. В результате для создания широкого перечня процедур и стандартов использовались идеи ARB и стандарты SAE. К 1996 г. все производители, продающие автомобили в США, должны были выполнять эти требования.

Так появилось второе поколение системы бортовой диагностики: On-Board Diagnostics II, или OBD II.


Как видим, концепция OBD II не была разработана в одночасье — она развивалась в течение многих лет. Вновь подчеркнем, что диагностика на основе OBD II — это не система управления двигателем, а набор правил и требований, которые должен соблюдать каждый производитель для того, чтобы система управления двигателем удовлетворяла федеральным нормам по составу выхлопных газов. Для лучшего понимания OBD II мы должны рассматривать ее по частям. Когда мы приходим к врачу, он не изучает наше тело целиком, а обследует различные органы. И только после этого результаты осмотра собираются воедино. Так мы и поступим при изучении OBD II. Опишем теперь те составляющие, которые должна иметь система OBD II для обеспечения стандартизации.


Автомобильные диагностические сканеры по протоколу OBD II :

    ELM327 USB это последняя версия популярного адаптера для диагностики автомобилей по протоколу OBDII. Осущетвляет диагностику по все протоколам OBDII (включая CAN). Работает при подключении к ПК через USB.

      

    Предназначен для чтения, стирания ошибок в бортовом компьютере автомобиля по протоколу OBDII. Прибор имеет небольшие размеры, малый вес и низкую цену, очень прост в использовании.

      

    Адаптер “Сканматик” служит для подключения персонального компьютера к диагностическому разъему автомобиля при работе с программой СКАНМАТИК. Объединяет в себе все протоколы OBD-2, протокол CAN, а так же поддерживает полную диагностику всех отечественных автомобилей.

Основная функция диагностического разъема (в OBD II он называется диагностическим разъемом связи — Diagnostic Link Connector, DLC) заключается в том, чтобы обеспечить связь диагностического сканера с блоками управления, совместимыми с OBD II. Разъем DLC должен соответствовать стандартам SAE J1962. Согласно этим стандартам, разъем DLC обязан занимать определенное центральное положение в автомобиле. Он должен находиться в пределах 16 дюймов от рулевого колеса. Производитель может разместить DLC в одном из восьми мест, определённых EPA. Каждый контакт разъема имеет свое назначение. Функции многих контактов отданы на усмотрение производителям, однако эти контакты не должны использоваться блоками управления, совместимыми с OBD II. Примерами систем, применяющих такие разъемы, являются SRS (дополнительная ограничительная система) и ABS (антиблокировочная система колес).

С точки зрения дилетанта, один стандартный разъем, находящийся в определенном месте, облегчает и удешевляет работу автосервиса. Автосервису не нужно иметь 20 различных соединительных разъемов или диагностических приборов для 20 различных автомобилей. Кроме того, стандарт экономит время, поскольку специалисту не приходится искать, где же находится разъем для подключения прибора.


Диагностический разъем изображен на рис. 1. Как видим, он имеет заземление и подсоединён к источнику питания (контакты 4 и 5 относятся к заземлению, а контакт 16 — к питанию). Это сделано для того, чтобы сканеру не требовался внешний источник питания. Если при подсоединении сканера питание на нем отсутствует, то необходимо в первую очередь проверить контакт 16 (питание), а также контакты 4 и 5 (заземление). Обратим внимание на буквенно-цифровые символы: J1850, CAN и ISO 9141-2. Это стандарты протоколов, разработанные SAE и ISO (Международная организация по стандартизации).


Производители могут делать выбор среди этих стандартов для обеспечения связи при диагностике. Каждому стандарту соответствует определённый контакт. Например, связь с автомобилями марки Ford реализуется через контакты 2 и 10, а с автомобилями GM — через контакт 2. В большинстве азиатских и европейских марок используется контакт 7, а в некоторых — также контакт 15. Для понимания OBD II не имеет значения, какой протокол рассматривается. Сообщения, которыми обмениваются диагностический прибор и блок управления, всегда одинаковы. Различны лишь способы передачи сообщений.

Стандартные протоколы связи для диагностики 

 

Итак, система OBD II распознает несколько различных протоколов. Здесь мы обсудим только три из них, которые используются в автомобилях, выпускаемых в США. Это протоколы J1850-VPW, J1850-PWM и ISO1941. Все блоки управления автомобиля связаны с кабелем, называемым диагностической шиной, в результате чего образуется сеть. К этой шине можно подключить диагностический сканер. Такой сканер отправляет сигналы конкретному блоку управления, с которым он должен обмениваться сообщениями, и получает ответные сигналы от этого блока управления. Обмен сообщениями продолжается до тех пор, пока сканер не прекратит сеанс связи или не будет отсоединен.


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

Классификация протоколов

Ассоциация автомобильных инженеров (SAE) определила три различных класса протоколов:

• протокол класса A, 
  
• протокол класса B 
  
• протокол класса C
  

Протокол класса A — самый медленный из трех; он может обеспечивать скорость 10 000 байт/с или 10 Кбайт/с. В стандарте ISO9141 используется протокол класса A.
Протокол класса B в 10 раз быстрее; он поддерживает обмен сообщениями со скоростью 100 Кбайт/с. Стандарт SAE J1850 представляет собой протокол класса B.
Протокол класса C обеспечивает скорость 1 Мбайт/c. Наиболее широко используемый стандарт класса C для автомобилей — это протокол CAN (Controller Area Network — сеть зоны контроллеров).

В будущем должны появиться протоколы с большей производительностью — от 1 до 10 Мбайт/с. По мере возрастания потребностей в увеличении полосы пропускания и производительности может появиться класс D. При работе в сети с протоколами класса C (а в будущем — с протоколами класса D) мы можем использовать оптическое волокно. Протокол J1850 PWM Существует два вида протокола J1850. Первый из них является высокоскоростным и обеспечивает производительность в 41,6 Кбайт/с. Данный протокол носит название PWM (Pulse Width Modulation — модуляция ширины импульса). Он используется в марках Ford, Jaguar и Mazda. Впервые такой тип связи был применен в автомобилях Ford. В соответствии с протоколом PWM сигналы передаются по двум проводам, подсоединенным к контактам 2 и 10 диагностического разъема.

Протокол ISO9141 

 

Третий из обсуждаемых нами протоколов диагностики — ISO9141. Он разработан ISO и применяется в большинстве европейских и азиатских автомобилей, а также в некоторых автомобилях Chrysler. Протокол ISO9141 не так сложен, как стандарты J1850. В то время как последние требуют применения специальных коммуникационных микропроцессоров, для работы ISO9141 нужны обычные последовательные коммуникационные микросхемы, которые лежат на полках магазинов.

Протокол J1850 VPW 
 

Другой разновидностью протокола диагностики J1850 является VPW (Variable Pulse Width — переменная ширина импульса). Протокол VPW поддерживает передачу данных со скоростью 10,4 Кбайт/с и применяется в автомобилях марок General Motors (GM) и Chrysler. Он очень похож на протокол, используемый в автомобилях Ford, но является существенно более медленным. Протокол VPW предусматривает передачу данных по одному проводу, подсоединенному к контакту 2 диагностического разъема.


С точки зрения дилетанта, OBD II использует стандартный диагностический коммуникационный протокол, так как Агентство по защите окружающей среды (EPA) потребовало, чтобы автосервисы получили стандартный способ, позволяющий качественно диагностировать и ремонтировать автомобили без затрат на покупку дилерского оборудования. Перечисленные протоколы будут более подробно описаны в последующих публикациях.

Лампочка индикации неисправностей 
 

Когда система управления двигателем обнаруживает проблему с составом выхлопных газов, на приборном щитке загорается надпись Check Engine (“Проверьте двигатель”). Этот индикатор называется лампочкой индикации неисправностей (Malfunction Indication Light — MIL). Индикатор обычно выдает следующие надписи: Service Engine Soon (“Отрегулируйте двигатель в ближайшее время”), Check Engine (“Проверьте двигатель”) и Check (“Выполните проверку”).

Назначение индикатора состоит в информировании водителя о том, что в процессе работы системы управления двигателем возникла проблема. Если загорается индикатор, не стоит впадать в панику! Вашей жизни ничто не угрожает, и двигатель не взорвется. Паниковать надо тогда, когда загорается индикатор масла или предупреждение о перегреве двигателя. Индикатор OBD II лишь сообщает водителю о проблеме в системе управления двигателем, которая может привести к избыточному количеству вредных выбросов из выхлопной трубы или загрязнению абсорбера.


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


Для того чтобы проверить функционирование индикатора OBD II MIL, следует включить зажигание (когда на приборном щитке загораются все индикаторы). При этом загорается и индикатор MIL. Спецификация OBD II требует, чтобы этот индикатор горел некоторое время. Некоторые производители делают так, чтобы индикатор оставался включенным, а другие — чтобы он выключался по истечении определенного промежутка времени. При запуске двигателя и отсутствии в нем неисправностей лампочка “Check Engine” должна погаснуть.

Лампочка “Check Engine” не обязательно загорается при первом появлении неисправности. Срабатывание этого индикатора зависит от того, насколько серьезна неисправность. Если она считается серьезной и ее устранение не терпит отлагательств, лампочка загорается немедленно. Такая неисправность относится к разряду активных (Active). В случае если устранение неисправности может быть отложено, индикатор не горит и неисправности присваивается сохраняемый статус (Stored). Для того чтобы такая неисправность стала активной, она должна проявиться в течение нескольких драйв-циклов. Обычно драйв-циклом считается процесс, при котором холодный двигатель запускается и работает до достижения нормальной рабочей температуры (при этом температура охлаждающей жидкости должна быть 122 градуса по Фаренгейту).


В течение этого процесса должны быть выполнены все бортовые тестовые процедуры, относящиеся к выхлопным газам. Различные автомобили имеют двигатели разного размера, и поэтому драйв-циклы для них могут несколько различаться. Как правило, если проблема возникает в течение трех драйв-циклов, то лампочка Check Engine должна загораться. Если же три драйв-цикла не выявляют неисправности, лампочка гаснет. Если лампочка Check Engine загорается, а затем гаснет, — не следует беспокоиться. Информация об ошибке сохраняется в памяти и может быть извлечена оттуда с помощью сканера. Итак, имеются два статуса неисправностей: сохраняемый и активный. Сохраняемый статус соответствует ситуации, когда неисправность обнаружена, но индикатор Check Engine не загорается — или же загорается, а затем гаснет. Активный статус означает, что при наличии неисправности индикатор горит.

Альфа-указатель DTC 

 

Как видим, каждый символ имеет свое назначение.
Первый символ принято называть альфа-указателем DTC. Этот символ указывает, в какой части автомобиля обнаружена неисправность. Выбор символа (P, B, C или U) определяется диагностируемым блоком управления. Когда получен ответ от двух блоков, используется буква для блока с более высоким приоритетом.

В первой позиции могут находиться лишь четыре буквы:

•     P (двигатель и трансмиссия); 
  
•     B (кузов); 
  
•     С (шасси); 
  
•     U (сетевые коммуникации). 
  

Стандартный набор диагностических кодов ошибок (DTC) 
 

В OBD II неисправность описывается с помощью диагностических кодов неисправностей (Diagnostic Trouble Code — DTC). Коды DTC в соответствии со спецификацией J2021 представляют собой комбинацию одной буквы и четырех цифр. На рис. 3 показано, что означает каждый символ. Рис. 3. Код ошибки

Типы кодов
 
 
Второй символ — наиболее противоречивый. Он показывает, что определил код. 0 (известный как код P0). Базовый, открытый код неисправности, определенный Ассоциацией автомобильных инженеров (SAE). 1 (или код P1). Код неисправности, определяемый производителем автомобиля. Большинство сканеров не могут распознавать описание или текст кодов P1. Однако такой сканер, как, например, Hellion, способен распознать большинство из них. Ассоциация SAE определила исходный перечень диагностических кодов ошибок DTC. Однако производители стали говорить о том, что у них уже есть собственные системы, при этом ни одна система не похожа на другую. Система кодов для автомобилей Mercedes отличается от системы Honda, и они не могут использовать коды друг друга. Поэтому ассоциация SAE пообещала разделить стандартные коды (P0) и коды производителей (P1).

Система, в которой обнаружена неисправность 
 
Третий символ обозначает систему, где обнаружена неисправность. Об этом символе знают меньше, но он относится к наиболее полезным. Глядя на него, мы сразу можем сказать, какая система неисправна, даже не глядя на текст ошибки. Третий символ помогает быстро идентифицировать область, где возникла проблема, не зная точного описания кода ошибки.

    Топливно-воздушная система.

•     Топливная система (например, инжекторы). 
  

    Система зажигания.

•     Вспомогательная система ограничения выбросов, например: клапан рециркуляции выхлопных газов (Exhaust Gas Recirculation System — EGR), система впуска воздуха в выпускной коллектор двигателя (Air Injection Reaction    System — AIR), каталитический конвертер или система вентиляции топливного бака (Evaporative Emission System — EVAP). 
  
•     Система управления скоростным режимом или холостым ходом, а также соответствующие вспомогательные системы. 
  
•     Бортовая компьютерная система: модуль управления двигателем (Power-train Control Module — PCM) или сеть зоны контроллеров (CAN). 
  
•     Трансмиссия или ведущий мост.  

Индивидуальный код ошибки 
 
Четвертый и пятый символы нужно рассматривать совместно. Они обычно соответствуют старым кодам ошибок OBDI. Эти коды, как правило, состоят из двух цифр. В системе OBD II также берутся эти две цифры и вставляются в конец кода ошибки — так ошибки легче различать.


Теперь, когда мы ознакомились с тем, как формируется стандартный набор диагностических кодов ошибок (DTC), рассмотрим в качестве примера код DTC P0301. Даже не глядя на текст ошибки, можно понять, в чем она состоит.

Буква P говорит о том, что ошибка возникла в двигателе. Цифра 0 позволяет заключить, что это базовая ошибка. Далее следует цифра 3, относящаяся к системе зажигания. В конце мы имеем пару цифр 01. В данном случае эта пара цифр говорит нам о том, в каком цилиндре имеет место пропуск зажигания. Собирая все эти сведения воедино, мы можем сказать, что возникла неисправность двигателя с пропусками зажигания в первом цилиндре. Если бы выдавался код ошибки P0300, это означало бы, что имеются пропуски зажигания в нескольких цилиндрах и система управления не может определить, какие именно цилиндры неисправны.

Самодиагностика неисправностей, приводящих к повышенной токсичности выбросов.

Программное обеспечение, управляющее процессом самодиагностики, называется по-разному. Производители автомобилей Ford и GM именуют его администратором диагностики (Diagnostic Executive), а Daimler Chrysler — диспетчером задач (Task Manager). Это набор программ, совместимых с OBD II, которые выполняются в блоке управления двигателем (PCM) и наблюдают за всем, что происходит вокруг. Блок управления двигателем — самая настоящая рабочая лошадка! В течение каждой микросекунды он выполняет огромное количество вычислений и должен определять, когда следует открывать и закрывать инжекторы, когда нужно подавать напряжение на катушку зажигания, каково должно быть опережение угла зажигания и т. д. Во время этого процесса программное обеспечение OBD II проверяет, все ли перечисленные характеристики соответствуют нормам.

Это программное обеспечение:

•     управляет состоянием лампочки Check Engine; 
  
•     сохраняет коды ошибок; 
  
•     проверяет драйв-циклы, определяющие генерацию кодов ошибок; 
  
•     запускает и выполняет мониторы компонентов; 
  
•     определяет приоритет мониторов; 
  
•     обновляет статус готовности мониторов; 
  
•     выводит тестовые результаты для мониторов; 
  
•     не допускает конфликтов между мониторами. 
  

Как показывает этот перечень, для того чтобы программное обеспечение выполняло возложенные на него задачи, оно должно обеспечивать и завершать работу мониторов в системе управления двигателем. Что же такое монитор? Его можно рассматривать как тест, выполняемый системой OBD II в блоке управления двигателем (PCM) для оценки правильности функционирования компонентов, ответственных за состав выбросов.

Согласно OBD II, имеется 2 типа мониторов: 

•     непрерывный монитор (работает все время, пока выполняется соответствующее условие); 
  
•     дискретный монитор (срабатывает один раз в течение поездки). 
  

Мониторы — очень важное понятие для OBD II. Они созданы для тестирования конкретных компонентов и обнаружения неисправностей в этих компонентов. Если компонент не может пройти тест, соответствующий код ошибки заносится в блок управления двигателем.

Стандартизация названий компонентов 

 

В любой области существуют различные названия и жаргонные словечки для обозначения одного и того же понятия. Возьмем, к примеру, код ошибки. Некоторые называют его кодом, другие — ошибкой, третьи — “штуковиной, которая сломалась”. Обозначение DTC — это и есть ошибка, код или “штуковина, которая сломалась”.

До появления OBD II каждый производитель придумывал свои имена компонентам автомобиля. Очень трудно было понять терминологию Ассоциации автомобильных инженеров (SAE) тому, кто пользовался названиями, принятыми в Европе. Теперь же благодаря OBD II во всех автомобилях должны использоваться стандартные имена компонентов. Жизнь стала намного легче для тех, кто ремонтирует автомобили и заказывает запасные части. Как всегда, когда во что-то вмешивается правительственная организация, сокращения и жаргон стали обязательными. Ассоциация SAE выпустила стандартизованный список терминов для компонентов автомобиля, относящихся к OBD II. Этот стандарт называется J1930. Сегодня по дорогам ездят миллионы автомобилей, в которых применяется система OBD II. Нравится это кому-то или нет — OBD II влияет на жизнь каждого человека, делая более чистым воздух вокруг нас. Система OBD II позволяет разрабатывать универсальные методики ремонта автомобилей и по-настоящему интересные технологии.

Поэтому можно смело сказать, что OBD II — мостик в будущее автомобилестроения.

Тема: 

Автосканеры по протоколу OBD 2

Архитектура приложения python для взаимодействия с obd-ii через can

Чтобы создать наше простое приложение на Python, мы будем использовать библиотеку Python CAN для управления сетью CAN. Вы также можете использовать API сокетов в Python для связи CAN, поскольку Python поддерживает CAN с версии 3.3, но на данный момент это более низкоуровневый подход.

Чтобы проиллюстрировать запрос OBD-II для PID 0x0C, как определено в стандарте для частоты вращения двигателя (RPM), мы представляем код ниже. Это будет:

1. Создайте интерфейс CAN-шины
2. Создайте ссылку на сообщение CAN для запроса
   1. Запрос сообщения CAN — это кадр CAN с DLC размером 8 байтов.
   2. Сообщение будет построено в следующем формате для стандарта SAE:
      • Байт 0 — количество дополнительных байтов: 2
      • Байт 1 — 1, чтобы показать текущие данные
      • Байт 2 — запрашиваемый PID-код
      • Байты с 3 по 7: они не используются, но ISO 15765-2 предлагает установить для них CCh
3. Отправьте запрос в главный ЭБУ с идентификатором 0x7DF
4. Получите сообщение и сравните его с ожидаемым идентификатором ответа 0x7E8
   1. Если мы получим сообщение от ожидаемого идентификатора ответа, он напечатает результат в шестнадцатеричном формате.

Чтобы выполнить наше приложение CAN, мы должны сначала настроить и включить сеть CAN в модуле. Интерфейс CAN1, физический, уже включен в его дереве устройств и обозначен как can0 на стороне Linux. Процесс настройки и включения может быть выполнен с помощью вызовов os.system () в Python, в которых мы настраиваем сеть CAN с битрейтом 500k.

Вы можете загрузить этот код в свою цель, скопировав и вставив его с помощью редактора nano, который мы установили в наш образ контейнера, как показано в его Dockerfile. Другой способ — привязать этот контейнер к /home/torizon, чтобы упростить отправку кода через scp.

Имея приложение под рукой, давайте попробуем его.

Краткий разговор о can

Прежде чем мы углубимся в технические детали приложения, вы должны знать, что оно будет использовать CAN, что означает сеть контроллеров. Это один из наиболее часто используемых протоколов связи для транспортных средств, грузовиков и даже тракторов. Если у вас есть автомобиль, произведенный после 2004 года, он наверняка имеет сеть CAN, соединяющую десятки ЭБУ.

Для тех, кто не знаком с этим термином, ЭБУ(ECU) — это аббревиатура от электронный блок управления (Electronic Control Unit). Он соответствует каждому электронному устройству в сети CAN, которое может принимать и передавать данные, отвечая за управление одной или несколькими функциями в транспортном средстве, такими как двигатель, трансмиссия и даже мультимедийная система.

Как правило, любой данный ЭБУ, действующий как узел CAN, способный взаимодействовать с шиной CAN транспортного средства, должен иметь два основных компонента: контроллер CAN, который реализует уровень канала передачи данных ISO 11898-1 для CAN, и приемопередатчик CAN, который, в свою очередь, заботится о физическом уровне в соответствии со стандартами ISO 11898-2 / 3, как показано на рисунке 1.

Первоначально шина CAN была предназначена для использования на транспортных средствах, но она оказалась настолько надежной, что ее начали использовать другие области, добавляя транспортные протоколы, чтобы она могла поддерживать больше приложений, таких как стандарт CAN J1939, созданный для грузовиков, и ISO-11783 (также известный как ISOBUS) создан для тракторов. OBD-II поверх CAN, о котором мы будем говорить, построен на ISOTP, или, другими словами, ISO-15765-2.

В том же направлении сеть CAN в большинстве транспортных средств также должна обмениваться данными по стандарту бортовой диагностики (OBD-II), в котором она должна отвечать на серию запросов, чтобы предоставить информацию о скорости, оборотах в минуту, уровне батареи, уровне топлива, среди множества других данных, связанных с информацией о двигателе.

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

Этот разъем обычно используется компаниями для телематических устройств для мониторинга, помимо других доступных переменных транспортных средств, скорости транспортного средства, уровня топлива, уровня заряда батареи, сгруппированных вместе с данными геолокации, полученными через приемник GPS / GNSS.

OBD-II — это подход «запрос-ответ». Другими словами, вам не придется читать не интересные вам сообщения по мере их появления. Вы будете отправлять сообщения главному ЭБУ транспортного средства, чтобы он реагировал на данную информацию, например, на скорость транспортного средства.

Главный ЭБУ автомобиля ответит на этот запрос, и вы обработаете сообщение в соответствии со стандартом OBD-II. Главное преимущество этого подхода заключается в том, чтобы не спамить шину CAN и периодически запрашивать интересующие сообщения, например, один раз в минуту.

Torizon и Verdin 

Если вы еще не слышали о Torizon, предлагаем вам взглянуть. Torizon — это простая в использовании промышленная встраиваемая Linux-платформа Toradex, которая использует приложения в контейнерах, управляемых Docker, с тем, чтобы облегчить разработку встроенных системных решений. Он также поставляется с клиентом OTA с безопасностью автомобильного уровня. Это открытый исходный код.

Вместе с Torizon Toradex уже предоставляет новое семейство компьютеров-на-модулях под названием Verdin, основанное на разъеме DDR4 SODIMM. Verdin имеет оптимизированный интерфейс, а также упрощенные требования к источнику питания и управлению питанием всей системы.

Он разработан для суровых условий, и его прямой выход позволяет добавлять реальные порты ввода-вывода без необходимости пересекать трассы или слои. Первые модули Verdin основаны на процессорах приложений i.MX 8M Mini, подобных показанному на рисунке 6, который использовался в этом примере.

NXP i.MX8 M Mini SoC не поставляется с собственными контроллерами CAN. Чтобы компенсировать это, Toradex добавила в модуль контроллер MCP2518 SPI CAN, как показано на рисунке 7. Контроллер CAN MCP2518 совместим с CAN-FD и является хорошим выбором для приложений CAN высокого класса.

В настоящее время есть две несущие платы, которые вы можете использовать для оценки компьютера-на-модуле Verdin: Dahlia и плата разработки Verdin. Dahlia — это компактная несущая плата, обеспечивающая легкий доступ к наиболее распространенным функциям семейства Verdin, а плата разработчика Verdin — это несущая плата, цель которой — раскрыть все функции модуля.

В этой демонстрации мы будем использовать плата разработки Verdin, но вы можете легко использовать Dahlia. Плата разработки Verdin использует изолированный CAN-трансивер ISO1042BDWR от Texas Instruments, который предоставляет все необходимые сигналы для CAN, такие как:

Мы предоставляем подробные инструкции по правильному использованию Verdin iMX8MM и платы разработки Verdin в Кратком руководстве от Toradex.

Поскольку TorizonCore является встроенным дистрибутивом Linux, он поддерживает SocketCAN, предоставляемый ядром Linux, что позволяет приложению взаимодействовать с сетью CAN как соединение сокета с Linux Socket API.

Теперь, когда все настроено, давайте сделаем шаг за шагом, чтобы вы могли установить TorizonCore 5 в свой Verdin iMX8MM и наше приложение-контейнер для связи CAN со стандартом OBD-II.

Тестирование нашего примера приложения с помощью симулятора obd-ii

У нас есть два способа проверить приложение CAN OBD-II:

1. Подключаем наше устройство к разъему OBD-II на транспортном средстве и начинаем общаться с реальным транспортным средством.
2. Использование другого устройства в качестве «ЭБУ» и ответа на запросы OBD-II по CAN.

Вариант 2 жизнеспособен, в противном случае потребовалось бы хорошее расширение мощности, чтобы мы могли попробовать его в машине автора этого обзора.

Сохраняя тему «Python», существует также проект Python виртуального ЭБУ для ответа на запросы OBD-II, называемый OBDSimulator. Мы использовали его на Colibri iMX6 с платой-носителем Viola, поэтому он будет вести себя как ЭБУ, отвечающий на наш Verdin iMX8MM по сети CAN между ними.

Использование несущей платы Viola было более сложной задачей при сборке установки с внешним трансивером CAN. Более простой способ — использовать оценочную плату Colibri для семейства Colibri или даже плату Ixora Carrier для семейства Apalis, поскольку эти несущие платы уже поставляются со встроенными трансиверами CAN, что делает их идеальными в качестве реализации эталонного дизайна. .

Схема, использованная для этого теста, показана на Рисунке 12. Для несущей платы Viola мы использовали приемопередатчик CAN SN65HVD230, так как iMX6 уже имеет контроллеры CAN. Он также использует резисторы 120 Ом на каждом конце «простой» сети CAN между ними.

С сервером OBDSimulator, работающим на Colibri iMX6 (как подробно описано в репозитории GitHub), мы выполнили следующие запросы на Verdin iMX8MM:

• Запросите текущие данные (режим 1) скорости двигателя (также известные как RPM, PID 0x0C):

Мы используем CAN в 11-битном формате, и после заданного запроса OBD-II ответ будет в следующем формате:

• Байт 0 — количество дополнительных байтов
• Байт 1 — 41h = отображение текущих данных
• Байт 2 — PID-код
• Байт 3 и выше — содержимое ответа на запрос.

В таблице OBD-II PID в Википедии информация о частоте вращения двигателя получается из содержимого запроса по следующей формуле:

Переменная A является третьим байтом в ответе, а переменная B — четвертым байтом (см. Ответ «Hex:» нашей команды выше). В OBDSimulator частота вращения двигателя составляет 514 об/мин. Давайте проверим, правда ли это?

((256 * 8)  8)/4 = 514

Это также показывает еще один ценный ресурс: обратите внимание на подробное описание каждого PID OBD-II, чтобы декодировать запрошенную информацию!

Мы можем изменить код, чтобы запросить другие PID OBD-II. Измените значение obd_req_data, чтобы теперь он запрашивал PID 0x0D (скорость автомобиля в км/ч) с текущими данными (режим 1):

Выполнение кода теперь даст нам вывод для запроса OBD-II PID 0x0D:

Если после повторного выполнения кода вы получаете сообщение «RTNETLINK отвечает: устройство или ресурс занят», это означает, что сетевой интерфейс уже настроен и работает.

В таблице OBD-II PID в Википедии информация о скорости транспортного средства получается как прямой результат третьего байта ответа, который является ответом на наш запрос. В OBDSimulator установлена скорость автомобиля 26 км / ч. Давайте проверим, правда ли это?

1A в шестнадцатеричном формате — 26 в десятичном. Так что, это!

Упрощение с помощью расширения torizon с кодом visual studio

Некоторые из вас могут быть не слишком знакомы с Docker и контейнерами. Это не проблема для работы с Torizon, знаете почему? Toradex также предоставляет вам расширение Torizon, доступное как для Visual Studio, так и для Visual Studio Code. С помощью расширения Torizon вы сможете быстро разрабатывать и загружать приложения в модуль с TorizonCore.

У использования нашего расширения Torizon для Visual Studio Code много преимуществ, не говоря уже о поддержке разработки приложений на следующих языках программирования:

Расширение Torizon позволяет развертывать и отлаживать ваше приложение в целевом объекте по сети всего за несколько щелчков мышью, имея также возможность управлять и отслеживать ваши устройства и контейнерные приложения с ними.

В этом конкретном примере мы покажем вам, как вы можете легко настроить приложение Python с помощью расширения Torizon для кода Visual Studio и запустить его на Verdin iMX8MM с установленным TorizonCore 5.

Давайте выполним следующие простые шаги для настройки:

1. Загрузите и установите Visual Studio Code и Torizon Extension в соответствии с инструкциями.
2. Имейте в виду, что вы должны настроить среду сборки для контейнеров Torizon, как мы объяснили выше.
3. Создайте новый проект Torizon / Python в коде Visual Studio

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

Вы можете видеть, что в коде Visual Studio в левой части экрана есть панель, содержащая значки каждого ресурса редактора. Одна из них — иконка Torizon. Щелкните по нему и настройте следующие параметры, наблюдая, что в каждом элементе появится значок типа « » или символ карандаша справа, который вы должны щелкнуть, чтобы добавить или отредактировать этот конкретный элемент:

См. Обзор этой части на рисунке 14.

По сути, это те изменения, которые мы внесли в Dockerfile вместе с командами «docker run», которые мы выполнили вручную выше. Но теперь Torizon Extension позаботится о всех формальностях за нас.

Теперь перейдите в меню «Проводник» в коде Visual Studio, затем откройте файл «main.py» вашего проекта. Скопируйте и вставьте тот же код, который мы использовали в примере командной строки выше.

Чтобы загрузить этот код на свою плату, где расширение Torizon уже запросило свои учетные данные (например, имя хоста / IP, пользователь и пароль), вы можете просто нажать F5 на клавиатуре. Затем утилита начнет создавать образ контейнера, загрузит его в устройство и начнет выполнение в режиме отладки, процесс, который вы можете наблюдать в разделе «Вывод» кода Visual Studio.

С помощью расширения Torizon и кода Visual Studio вы также можете добавлять точки останова в свое приложение для отслеживания частей процесса выполнения программы. На рис. 15 показан пример выполнения приведенной выше программы с точками останова.