Протокол соединения с эбу

Опубликовано: 19.05.2024

1. OEM (протокол производителя).
Коммутация +12в. при включении зажигания.
2. Шина + (Bus positive Line). SAE-J1850 PWM, SAE-1850 VPW.
3. —
4. Заземление кузова.
5. Сигнальное заземление.
6. Линия CAN-High высокоскоростной шины CAN Highspeed (ISO 15765-4, SAE-J2284).
7. K-Line (ISO 9141-2 и ISO 14230).
8. —
9. Линия CAN-Low, низкоскоростной шины CAN Lowspeed.
10. Шина — (Bus negative Line). SAE-J1850 PWM, SAE −1850 VPW.
11. —
12. —
13. —
14. Линия CAN-Low высокоскоростной шины CAN Highspeed (ISO 15765-4, SAE-J2284).
15. L-Line (ISO 9141-2 и ISO 14230).
16. Питание +12в от АКБ.

SAE J1850 PWM

Существует два типа протокола J1850. PWM является высокоскоростным и обеспечивает передачу информации со скоростью 41,6 Кбайт/с. Он применяется в автомобилях марок Ford, Jaguar и Mazda. В протоколе PWM сигналы передаются по двум проводам, подсоединенным к 2 и 10 контакту диагностического разъема.

SAE J1850 VPW

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

Данный протокол разработан компанией 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 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 Мбит/с.

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

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

В шину диагностики втыкается адаптер ЕЛМ327 и по воздуху он соединяется с планшетом, телефоном, смартом, где установлена и запущена программа TorquePro

Для того, что бы понять что на картинке, нужно знать следующие вещи:
Протокол ОБД2 из википедии. ru.wikipedia.org/wiki/OBD-II_PIDs
Протокол ОБД2 из википедии, более подробный en.wikipedia.org/wiki/OBD-II_PIDs
Протокол ISO9141-2 embeddedsystem.ru/index.p…=protokoly-standarta-obd2
С поиском протколов уже гораздо все хуже. Так как у меня этот протокол, так и буду описывать только его.
OBD2 распиновка — prohelps.ru/raspinovka-obd2-razema/
ELM327, описание АТ команд — www.sparkfun.com/datashee…ts/ELM327_AT_Commands.pdf

А теперь подключаем анализатор к тестовому компьютеру двигателя Toyota 2ZZ-GE, и "разбираем" по полочкам данные. Они такие:

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

1. — Под цифрой 1 идет фрейм так называемой первоначальной инициализации соединения. На этом этапе микроконтроллер должен передать 8 битное "приветствие" с частотой 5 бит в секунду. Первый импульс, это как и положено протоколу UART стартовый бит, который говорит о том, что следом за ним пойдут данные. Стоповый бит на картинке не указан. Узнать, какое значение должно быть можно и поиска строк инициализации под свою машину для проги Torque. В ЕЛМ за это отвечает команда ATIIA. После того, как приветствие передано, мозги 2ZZ-GE через 0.3 секунды ответили:
2. — Это три байта, которые отправят ECU Первый байт, это байт синхронизации. передается он на той частоте, на которой ECU желает с нами общаться. Для 2ZZ-GE это 9600б\с Дальше через 7.3 миллисекунды следуют два байта KW1 и KW2, у меня это 0хЕ9 и 0x8F. Далее следует пауза в 31мс . Следует учесть, что пауза после приема обусловлена задержкой передачи от софта в ЕЛМ и с него в шину. Так что привязываться к ней не стоит.
3. — Проверка на ошибки. Это два байта. Первый байт отравляет микроконтроллер, это инверсия принятого ранее байта KW2, второй байт — это отклик ECU с инверсией первоначального адреса.

Все, после этого считается, что все подружилось, и можно отправлять команды запросов и получать ответы на эти запросы.

4. — Пример запроса "Температура охлаждающей жидкости" Первый отправляется хeдер. Это значение, которое в Torque указано командой ATSH. Далее, согласно стандарту ОДБ передается 0x01. Show current data — Считывание текущих параметров работы системы управления. После него идет сам пид датчика. Для запроса температуры ОЖ он имеет значение 0х05 Завершает запрос байт контрольной суммы. Если запрос был успешным, то ECU ответит. Если что то в запросе будет не то, то ECU просто промолчит. Ответ:

5. — Ответ начинается с хeдера ECU. Для режима опроса датчиков он всегда один и тот же, для других режимов (чтение ошибок и т.п.) он другой. После этого следует номер запрашиваемого пида для проверки и значение показания датчика. Завершает ответ байт контрольной суммы. Все.

Формула расчета показания датчика есть в таблице описания протокола ОБД на Википедии.

Данные ответа могут быть различной длинны, например в два байта, или как запрос на активные пиды у меня дает ответ в 10 байт.

Таблица пидов не всегда соответствует тому, что там написано. Производители могут что то сами мутить с адресами и отходить от стандартов. К примеру, на моторах 1ZZ-FE пид данных температуры АКПП имеет значение 0хВ4 с ответом в два байта с формулой расчета (А/256)-40, он не виден в запросе списка пидов и не выделяется цветом активного датчика в Torque

Подсчет контрольной суммы обычный классический, пример:
0х82+0х13+0хF1+0x01+0x05=0x 01 8C
Все данные запроса или приема суммируются и в итоге подсчета отсекается все, кроме первых двух бит

Ради интереса, срисовал передающую часть K-Line шины электросхемы ECU 2ZZ-GE:

Можно сказать, что схема имеет вид "открытый коллектор" с цепями защиты и легкой подтяжкой к шине питания.

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

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

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

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

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

В рамках диагностического стандарта OBDII существует 5 основных протоколов обмена данными между электронным блоком управления (ЭБУ) и диагностическим сканером. Физически подключение автосканера к ЭБУ производится через разъем DLC (Diagnostic Link Connector), который соответствует стандарту SAE J1962 и имеет 16 контактов (2x8). Ниже представлена схема расположения контактов в разъеме 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 включает:

SOF - Start of Frame (начало кадра, высокий импульс на 200uS);

Header - заголовок длиной 1 байт;

CRC - Cyclic Redundancy Check (циклический избыточный код, 1 байт);

EOD - End Of Data (окончание данных, низкий импульс на 200uS).

Если рассматривать формат протокола более подробно по битам, то он примет следующий вид:

Реальный пример сигнала SAE J1850 выгладит следующим образом:

SAE J1850 VPW

ISO 9141-2

В общем виде процесс инициализации сигнала в протоколах ISO 9141 и ISO 14230 выглядит следующим образом:

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

ISO 14230-4 (др. название Keyword Protocol 2000)

ISO 15765 CAN

Команда EmbeddedSystem занимается разработкой широкого спектра электронной продукции, включая разработку и производство электроники для автомобилей, автобусов и грузовиков. Возможна разработка и поставка электроники, как на коммерческих, так и на партнерских условиях. Звоните! Примеры проектов.

VAG 1. 14, CE - Audi, Seat, Skoda, Volkswagen в основном с 1990 г.в.

Tiggo - Chery Tiggo, GreatWall Hover, BYD F3 и др. до 2008 г.в.

Авео 1, 2 - Chevrolet (Aveo, Lacetti, Rezzo, Lanos), Daewoo Nexia (после 2008 г.в.) - ЭБУ HV240, MR140, Sirius-D4, Sirius-D42

ДЭУ 1. 3 - Daewoo (Lanos, Nexia, Nubira, Leganza) до 2008 г.в. - ЭБУ IEFI-6, ITMS-6F, IEFI-S

Daihat - Daihatsu после 2000 г.в.

GreatWall - GreatWall Safe, Deer и др. до 2008 г.в. - ЭБУ Bosch

Honda - Honda до 2001 года выпуска

Mitsu 1. 5 - Mitsubishi с 12- и 16-контактными колодками диагностики

Consult1, Consult1D - Nissan до 2000 г.в., протокол «Consult-1»

Nissan - Nissan после 2000 года с 16-контактной колодкой диагностики

Opel 1. 8 - Opel 1997. 2003 г.в.

Рено - Renault Logan, Symbol, Kangoo - ЭБУ Siemens EMS3132

Sonata - - Hyundai Sonata V (EF new) с двигателями "BETA"

SsYong бен - SsangYong Rexton 2.8 (бензин)

SsYong диз1 - SsangYong Actyon 2.0 (дизель), Kyron 2.0 (дизель), Rexton 2.7 (дизель XDI)

SsYong диз2 - SsangYong Rexton 2.7 (дизель XVT)

Subaru - Subaru 1999. 2005 г.в.

Suzuki - Suzuki Escudo, Vitara

TOBD1 - Toyota до 1998 г.в.

Toyota - Toyota 1998. 2003 г.в.

CAN Toyota - Toyota 2004. г.в.

Микас 10.3 - Daewoo Sens, Zaz Chance (ЭБУ Микас 7.6; Микас 10.3)

"Январь" - Январь 5.1; Bosch 1.5.4 (N); VS 5.1 Ителма; Январь 7.2 (+)

"Бош М7.0" - Bosch MP7.0

"Бош М7.9.7" - Bosch М7.9.7 (+); М73

"М74" - Итэлма М74; Bosch ME17.9.7; Итэлма М75

"M74CAN" - М74 CAN

"Микас" - Микас 5.4, 7.1, 7.2; СОАТЭ 301, 302, 309; Ителма VS5.6

"Микас 11" - Микас 11; Ителма VS8

"Микас 11Е3" - Микас 11ET; Микас 11CR

"Микас 10.3" - Микас 10.3; Микас 12.3

"UAZ 1797" - Bosch ME 17.9.7, Bosch ME 17.9.71

"EDC16 IVECO" - Bosch EDC16C39 (дизельный двигатель Iveco F1A 2.3)

"EDC16 ЗМЗ"- Bosch EDC16C39-6.H1 (дизельный двигатель ЗМЗ-51432)

"М12" - Микас 12 Э9867.3763 001-01 (с двухтопливной системой питания)

"Крайслер" - "Daimler Chrysler" DCC 2.4L DOHC Motorola

"J1939" - Газель с дизельным двигателем Cummins ISF2.8s3129T

"Микас 7.6" - Микас 7.6; Микас 10.3

АПС-6 - иммобилайзер АПС-6, АПС-6.1, АПС-6.1 (комплектация "Люкс")

САУО - система автоматического управления отопителем

САУКУ - система автоматического управления климатической установкой

Visteon - климатическая установка Visteon

ЭМУР - электромеханический усилитель руля (Калуга, Махачкала, Mando)

СНПБ - система надувных подушек безопасности

СНПБ Ш-Н - система надувных подушек безопасности "Chevrolet-NIVA"

Takata - подушки безопасности "Lada Granta"

Электропакет - блок управления электропакетом "Приора", "Норма", "Люкс", "Гранта"

МДВ - модуль двери водителя "Калина Люкс"

БУСО - блок управления стеклоочистителем

ABS 8 / 9 - антиблокировочная система Bosch ABS 8 / 9

Bosch ABS/ESP9 - система стабилизации Bosch ABS/ESP9

АКПП Jatco AY-K3 - автоматическая коробка передач "Lada-Granta"

ABS 5.3 - антиблокировочная система Bosch ABS 5.3

ABS 8 / 9 - антиблокировочная система Bosch ABS 8 / 9

Электропакет БУЭП 3163-6512020

Пульт климатической установки

AWD Dymos - раздаточная коробка Dymos с электронным управлением

Важно! для диагностики AWD "Dymos" необходимо выключить зажигание автомобиля, перейти в "Дисплей ТО - Ошибки/Диагностика - Доп. системы", выбрать строку "UAZ AWD Dymos(2)", нажать "SET" и незамедлительно включить зажигание автомобиля.

Любой автомобиль, оснащенный электронной системой впрыска топлива и электронным датчиком скорости.

Читайте также: