Хакаем CAN шину авто. Мобильное приложение вместо панели приборов
Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.
По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.
Программный сниффер VCDS
Чтобы узнать по какому протоколу общаются электронные блоки я использовал специальную версию VCDS с программным сниффером в комплекте. В этот раз никаких железных снифферов на Arduino или RPi не пришлось изобретать. С помощью CAN-Sniffer можно подсмотреть общение между VCDS и автомобилем, чтобы затем телефон мог прикинуться диагностической утилитой и отправлять те же самые запросы.
Я собрал некоторую статистику по использованию диагностических протоколов на разных моделях автомобилей:
VW/Skoda/Seat (2006-2012) — приборная панель UDS. Двигатель и трансмиссия VW TP 2.0
Audi (2006-2012) — приборная панель VW TP 2.0. Двигатель UDS. Трансмиссия VW TP 2.0
VW/Skoda/Seat/Audi (2012-2021) — везде UDS
Протокол UDS
Unified Diagnostic Services (UDS) — это диагностический протокол, используемый в электронных блоках управления (ЭБУ) автомобильной электроники. Протокол описан в стандарте ISO 14229-1 и является производным от стандарта ISO 14230-3 (KWP2000) и ныне устаревшего стандарта ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN)). Более подробно в википедии.
Диагностические данные от двигателя по протоколу UDS (Skoda Octavia A7)
В моей машине (Skoda Octavia A5) приборка использует UDS протокол, это дало мне легкий старт разработки, т.к. данные были в простом формате Single Frame SF (фрейм, вся информация которого умещается в один CAN пакет) и большинство значений легко поддавались расшифровке. Volkswagen не дает документацию на формат значений, поэтому формулу расшифровки для каждого датчика приходилось подбирать методом логического мышления. Про UDS протокол очень хорошо и с подробным разбором фреймов написано на canhacker.ru.
Разбор UDS пакета в формате Single Frame
Пример запроса и ответа температуры моторного масла:
Запрос температуры моторного масла:
7E0 — Адрес назначения (ЭБУ двигателя)
Байт 0 (0x03) — Размер данных (3 байта)
Байт 1 (0x22) — SID идентификатор сервиса (запрос текущих параметров)
Байт 2, 3 (0x11 0xBD) — PID идентификатор параметра (температура моторного масла)
Байт 4, 5, 6, 7 (0x55) — Заполнитель до 8 байт
Ответ температуры моторного масла:
7E8 — Адрес источника (Диагностический прибор)
Байт 0 (0x05) — Размер данных (5 байт)
Байт 1 (0x62) — Положительный ответ, такой SID существует. 0x22 + 0x40 = 0x62. (0x7F) — отрицательный ответ
Байт 2, 3 (0x11 0xBD) — PID идентификатор параметра (температура моторного масла)
Байт 4, 5 (0x0B 0x74) — значение температуры моторного масла (20.1 °C формулу пока что не смог подобрать)
Байт 6, 7 (0x55) — Заполнитель до 8 байт
Первая версия мобильного приложения VAG Virtual Cockpit умела подключаться только к приборной панели по UDS.
VAG Virtual Cockpit — экран с данными от приборной панели по протоколу UDS
VW Transport Protocol 2.0
Volkswagen Transport Protocol 2.0 используется в качестве транспортного уровня, а данные передаются в формате KWP2000. Keyword Protocol 2000 — это протокол для бортовой диагностики автомобиля стандартизированный как ISO 14230. Прикладной уровень описан в стандарте ISO 14230-3. Более подробно в википедии.
Т.к. KWP2000 использует сообщения переменной длины, а CAN шина позволяет передавать сообщения не больше 8 байт, то VW TP 2.0 разбивает длинное сообщение KWP2000 на части при отправке по CAN шине и собирает заново при получении.
Диагностические данные от двигателя по протоколу KWP2000 (Skoda Octavia A5)
ЭБУ двигателя моей машины использует протокол VW TP 2.0, поэтому мне пришлось изучить его. Видимо Volkswagen разрабатывала транспортный протокол не только для работы по надежной CAN шине, но и для менее надежных линий связи, иначе нет объяснения для чего требуется такая избыточная проверка целостности данных. Главным источником информации по VW TP 2.0 является сайт https://jazdw.net/tp20.
Разбор протокола VW TP 2.0 на примере подключения к первой группе двигателя:
Настраиваем канал с двигателем. Байт 0: 0x01 — двигатель, 0x02 — трансмиссия. Байт 5,4: 0x300 — адрес источника
Получили положительный ответ. Байт 5,4: 0x740 — к двигателю обращаемся по этому адресу
Настраиваем ЭБУ на отправку сразу 16 пакетов и выставляем временные параметры
Получили положительный ответ
Отправляем команду KWP2000 startDiagnosticSession. Байт 0: 0x10 = 0b0001 — последняя строка данных + 0x0 счетчик отправляемых пакетов 0 (0x0 — 0xF)
Получили положительный ответ. Байт 0: 0x10 — cчетчик принимаемых пакетов 0
Мы отправили первый ACK, что получили ответ
Делаем запрос. Байт 0: 0x11 — счетчик отправляемых пакетов 1. Байт 3: 0x21 — запрос параметров. Байт 4: 0x01 — из группы 1
300 22 00 1A 61 01 01 C8 13
Байт 0: 0x22 — 0b0010 (не последняя строка данных) + 0x02 (cчетчик принимаемых пакетов 2). Байт 1,2: 0x00 0x1A длина 26 байт. Байт 3,4: 0x61 0x01 — положительный ответ на команду запроса параметров 0x21+0x40=0x61 из 0x1 группы. Байт 5: 0х01 — Запрос RPM (соответсвует протоколу KW1281). Байт 6,7: (0xC8 * 0x13)/5 = 760 RPM (формула соответствует протоколу KW1281)
300 23 05 0A 99 14 32 86 10
Байт 1: 0x05 — запрос ОЖ. Байт 2,3: (0x0A * 0x99)/26 = 57.0 C. Байт 4: 0x14 = запрос лямбда контроль %. Байт 5,6: 0x32*0x86; Байт 7: 0х10 — двоичная настройка
300 24 FF BE 25 00 00 25 00
0x25 0x00 x00 — Заполнитель, до 8 параметров
300 15 00 25 00 00 25 00 00
Байт 0: 0x15 — 0b0001 (последняя строка данных) + 0x5 (счетчик принимаемых пакетов 5)
Отправляем ACK. Прибывляем к нашему предыдущему ACK количество полученных пакетов 0xB1 + 0x4 = 0xB5
Запрос KeepAlive, что мы еще на связи
ЭБУ в ответ тоже разрывает связь
Во второй версии мобильного приложения VAG Virtual Cockpit появилась возможность диагностировать двигатель и трансмиссию по протоколу VW TP 2.0.
VAG Virtual Cockpit — экран с данными от двигателя по протоколу VW TP 2.0
Диагностический адаптер ELM327
Для меня некоторое время было вопросом, как получить данные из CAN шины и передать на телефон. Можно было бы разработать собственный шлюз с Wi-Fi или Bluetooth, как это делают производители сигнализаций, например Starline. Но изучив документацию на популярный автомобильный сканер ELM327 понял, что его можно настроить с помощью AT команд на доступ к CAN шине.
Копия диагностического сканера ELM327 Не все ELM327 одинаково полезны
Оригинальный ELM327 от компании elmelectronics стоит порядка 50$, в России я таких не встречал в продаже. У нас продаются только китайские копии/подделки, разного качества и цены 10-30$. Бывают полноценные копии, которые поддерживают все протоколы, а бывают и те которые умеют отвечать только на несколько команд, остальные игнорируют, такие адаптеры не имеют доступ к CAN шине. Я например пользуюсь копией Viecar BLE 4.0, который поддерживает 100% всех функций оригинала.
Для работы с протоколом UDS через ELM327 нужно указать адреса назначения, источника и разрешить длинные 8 байтные сообщения, по умолчанию пропускается максимум 7 байт.
Последовательность ELM327 AT команд для работы с UDS по CAN шине:
Для работы с протоколом KWP2000 через ELM327 нужно только указать адреса назначения и источника.
Последовательность ELM327 AT команд для работы с VW TP 2.0 по CAN шине:
Мобильное приложение VAG Virtual Cockpit
Для разработки мобильного приложения подключаемого к автомобилю требовалось:
Сниффером собрать трафик от диагностической утилиты VCDS
Изучить работу протоколов UDS, VW TP 2.0, KWP2000
Настроить диагностический сканер ELM327 на работу с UDS и VW TP 2.0
Изучить новый для меня язык программирования Swift
Мобильное приложение VAG Virtual Cockpit для iOS
В итоге получилось приложение, которое сочетает в себе функции отображения точных данных панели приборов и диагностика основных параметров двигателя и трансмиссии.
Пару слов про точность данных. Штатная панель приборов не точно показывает скорость — завышает показания на 5-10 км/ч, стрелка охлаждающей жидкости всегда на 90 °C, хотя реальная температура может быть 80 — 110 °C, стрелка уровня топлива до середины идет медленно, хотя топлива уже меньше половины и при нуле на самом деле топливо еще есть в баке. Производитель это делает для удобства и безопасности водителя.
На данный момент приложение показывает следующие параметры:
Приборная панель
Трансмиссия (температура)
1) Какая дверь открыта
2) Скорость
3) Обороты
4) Температура масла
5) Температура ОЖ
6) Топливо в баке в л.
7) Запас хода в км.
8) Средний расход
9) Время в машине
10) Пробег
11) Температура за бортом
1) Обороты
2) Массовый расход воздуха
3) Температура забора воздуха
4) Температура выхлопа (рассчитанная)
5) Критический уровень масла
6) Уровень масла
7) Наддув турбины (реальный)
8) Наддув турбины (ожидаемый)
9) Пропуски зажигания в цилиндрах
10) Углы откатов зажигания в цилиндрах
1) ATF AISIN (G93)
2) DSG6 (G93)
3) Блок управления DSG6 (G510)
4) Масло диска сцепления DSG6 (G509)
5) Мехатроник DSG7 (G510)
6) Процессор DSG7
7) Диск сцепления DSG7
Я стремлюсь чтобы приложение поддерживало как можно больше моделей автомобилей. Пока что поддерживаются производители: Volkswagen, Skoda, Seat, Audi. На разных комплектациях могут отображаться не все параметры, но это поправимо.
Сейчас я провожу тестирование версии 3.0. Приложение доступно только на iOS, после релиза 3.0 перейду к разработке версии для Android.
Если интересно потестировать и есть желание принять участие в проекте, то установить приложение можно по ссылке. Также я веду бортжурнал на drive2.ru, где делюсь полезной информацией и новостями о VAG Virtual Cockpit.
Can шина сброс ошибок
Controller Area Network (шина данных CAN)
В период с 1984 по 1986 г.г., компанией Robert Bosch GmbH был придуман, разработан и воплощен в производство стандарт CAN — Controller Area Network (сеть контроллеров) , основной целью которого является объединение в единую сеть различных исполнительных устройств, датчиков, сенсоров и т.п.
И как оказалось впоследствии, шина данных CAN действительно имела множество преимуществ перед обычными жгутами проводов, причислим некоторые:
Раньше об этом понятии задумывались мало или вообще не задумывались. Потому что автомобилям хватало небольшого пучка проводов и пару-тройку устройств для нормальной работы двигателя внутреннего сгорания.
Однако технический прогресс идет вперед, вопросы экологии, безопасности дорожного движения и водителя, как участника этого движения, выходят на первое место, что приводит к постоянному увеличению количества электронных устройств на автомобиле.
Что такое «Электромагнитная совместимость на автомобиле»?
Это способность одновременного и стабильного функционирования множества различных электронных устройств на автомобиле без создания электромагнитных помех друг другу .
Шина CAN как раз отвечает этим важным требованиям.
Более конкретно об этом вопросе чуть позже.
Уменьшение количества кабельных соединений
Сначала немного о том, что же такое эта шина и как она выглядит:
Шина данных CAN – это обычная «витая пара», вот как на фото справа. Это специально скрученный двухжильный провод.
К этой витой паре подключены различные блоки управления – их называют «пользователи». Передача данных идет одновременно по двум проводам этой «витой пары». Важно знать, что логические уровни шины имеют зеркальное отображение: если по одному проводу передается уровень логического «нуля», то по другому проводу одновременно передается уровень логической «единицы».
Почему используется двухпроводная схема передачи данных:
- для стабильности распознавания ошибок
- для увеличения и повышения надёжности работы по передаче данных
Предположим, что пик напряжения возникнет только на одном проводе (например, вследствии проблем по электромагнитной совместимости) .
И тогда блоки-приёмники могут идентифицировать это как ошибку и проигнорировать данный пик напряжения.
Если же произойдет короткое замыкание или обрыв одного из двух проводов, то благодаря интегрированной программно-аппаратной концепции надёжности произойдёт переключение в режим работы по однопроводной схеме, и повреждённая передающая линия использоваться не будет.
Так вот, продолжим о «уменьшении количества соединений между устройствами шины CAN»:
- Провода от датчиков проводятся только к ближайшему блоку управления, который преобразует измеренные значения в пакет данных и передаёт его на шину данных CAN.
Уменьшение количества штекерных соединений
Уменьшение количества контактных выводов на блоках управления
А сейчас давайте посмотрим, что представляет из себя «пакет данных» шины CAN. Он состоит из семи последовательных полей (отрезков).
На приведенном внизу рисунке показано восемь полей, последнее Intermission – « Пауза между пакетами данных» и оно не входит в Data Frame :
Цифры в каждом поле показывают количество битов, используемых в каждом сообщении (пакете данных).
Описание полей пакета данных Start of Frame
Маркирует начало сообщения (стартов, бит) и синхронизирует все модули шины.
Это поле состоит из идентификатора адреса в 11 бит и 1 контрольного бита и запрос (Remote Transmission Request-Bit).
Этот контрольный бит маркирует пакет как Data Frame (фрейм сообщения) или как Remote Frame (фрейм запроса) без байтов данных.
Control Field (управл. биты)
Поле управления (6 бит) содержит бит IDE (Identifier Extension Bit) для распознавания стандартного и расширенного формата, резервный бит для последующих расширений и — в последних 4 битах — количество байтов данных, заложенных в Data Field (поле данных).
Поле данных может содержать от 0 до 8 байт данных. Сообщение по шине данных CAN длиной 0 байт используется для синхронизации распределённых процессов
CRC Field (контрольное поле)
Поле CRC (Cyclic-Redundancy-Check Field) содержит 16 бит и служит для контрольного распознавания ошибок при передаче данных.
АСК Field (подтверждение приема)
Поле АСК (Acknowledgement Field) содержит сигнал квитирования всех блоков-приёмников, получивших сообщение по шине данных CAN без ошибок (квитирование — подтверждение приема, отправка квитанции — управляющее сообщение или сигнал, выдаваемые в ответ на принятое сообщение) .
End of Frame (конец фрейма)
Маркирует конец пакета данных
Интервал между двумя пакетами данных. Интервал должен составлять не менее 3 битов. После этого любой блок управления может передавать следующий пакет данных.
Если ни один блок управления не передаёт сообщений, то шина данных CAN остается в режиме покоя до передачи следующего пакета данных.
Шина данных CAN является двунаправленной шиной — любой из подключённых блоков может, как передавать, так и принимать сообщения.
На приведенном выше рисунке слово Dashboard можно заменить на привычное (разговорное и чаще применяемое) «Шлюз».
К примеру на некоторых автомобилях, шлюзом между быстрой и медленной шиной является панель приборов (Ауди,Фольксваген), у Мерседеса функции шлюза выполняет EZS (замок зажигания), хотя сама панель работает в двух сетях, для отображения как салонной, так и моторной информации.
На следующих поколениях автомобилей с 2002 года начали использовать отдельный блок ZGW (центральный интерфейс), который выполняет функции шлюза, хранит кодировки комплектации авто и через него работает диагностика по CAN шине (именно по «чистому» CAN – без к-линий).
Шины данных CAN существуют с различными скоростями передачи данных и их иногда называют «быстрая шина» (High-Speed-CAN ) и «медленная шина» (Low- Speed-CAN).
Например, High-Speed-CAN – это шина двигателя, АКПП и т.п., имеет скорость передачи данных 500 Кбит
Low-Speed-CAN — это шины для управления стеклоподъемниками, кондиционером и т.п. , со скоростью передачи данных 100 Кбит.
Порядок и формат передачи и приёма сообщений пользователями определён в протоколе обмена данных.
Существенным отличительным признаком шины данных CAN по сравнению с другими шинными системами, базирующимися на принципе абонентской адресации, является соотнесённая с сообщением адресация.
- каждому сообщению по шине данных CAN присваивается его постоянный адрес (идентификатор), маркирующий содержание этого сообщения (например: температура охлаждающей жидкости).
Блок-приёмник обрабатывает только те сообщения (пакеты данных), которые сохранены в его списке принимаемых по шине данных CAN сообщений (контроль назначения сообщения).
Пакеты данных могут передаваться только в том случае, если шина данных CAN свободна (то есть, если после передачи последнего пакета данных последовал интервал в 3 бита, и никакой из блоков управления не начинает передавать сообщение). При этом логический уровень шины данных является рецессивным (логическая «1»)
Шина данных CAN: РАСШИРЕННЫЕ ВОЗМОЖНОСТИ проведения Диагностики
Так как сигналы с одного датчика (например, датчика температуры, датчика скорости и др.), может использоваться различными системами, то в том случае, если наличие неисправности отображают все использующие данный сигнал системы, неисправным является, как правило, датчик или блок управления, обрабатывающий его сигналы.
Если же сообщение о неисправности поступает только от одной системы, хотя данный сигнал используется и другими системами, то причина неисправности, в большинстве случаев, заключается в обрабатывающем этот сигнал блоке управления или сервомеханизме
Высокий уровень защиты передаваемых данных
Высокий уровень защиты передаваемых данных беспечивается даже при сильных помехах.
При этом обеспечивается высокая скорость передачи данных (до 1 Mbit/s)
За счет чего это достигается:
- Механизм обнаружения ошибок Механизм исправления ошибок
Сохранение работоспособности при высоком уровне электромагнитных помех
Распределение приоритетов команд
Помехи при передаче данных могут приводить к возникновению ошибок. Такие ошибки при передаче данных надо распознавать и устранять. Протокол шины данных CAN различает два уровня распознавания ошибок:
- механизмы на уровне Data Frame (фрейм сообщения)
на основе передаваемого по шине данных CAN сообщения модуль-передатчик рассчитывает контрольные биты, которые передаются вместе с пакетом данных в поле «CRC Field». Модуль-приёмник заново вычисляет эти контрольные биты на основе принятого по шине данных CAN сообщения и сравнивает их с контрольными битами, полученными вместе с этим сообщением.
Этот механизм проверяет структуру передаваемого фрейма, то есть перепроверяются битовые поля с заданным фиксированным форматом и длина фрейма.
Распознанные функцией Frame Check ошибки обозначаются как ошибки формата.
Механизмы на уровне битов
Каждый модуль при передаче сообщения отслеживает логический уровень шины данных CAN и на основе этого распознаёт различия между переданным и принятым битом. Благодаря этому обеспечивается надёжное распознавание глобальных и возникающих в блоке-передатчике локальных ошибок по битам.
В каждом пакете данных между полем «Start of Frame» и концом поля «CRC Field» должно быть не более 5 последовательных битов с одинаковой полярностью. После каждой последовательности из 5 одинаковых битов блок-передатчик добавляет в поток битов один бит с противоположной полярностью. Блоки- приёмники, в свою очередь, удаляют эти биты после приёма сообщения по шине данных CAN.
Механизм устранения ошибок
Если какой-либо модуль шины данных CAN распознаёт ошибку, то он прерывает текущий процесс передачи данных, отправляя сообщение об ошибке. Сообщение об ошибке состоит из 6 доминантных битов.
Благодаря этому сообщению об ошибке все подключённые к шине данных CAN блоки управления оповещаются о возникшей локальной ошибке и, соответственно, игнорируют переданное сообщение.
После короткой паузы все блоки управления снова смогут передавать сообщения по шине данных CAN, причём первым опять будет отправлено сообщение с наивысшим приоритетом (мотор, АКПП и т.п.).
Блок управления, чьё сообщение по шине данных CAN обусловило возникновение ошибки, также начинает повторную передачу своего сообщения (Automatic Repeat Request — автоматический повтор запроса).
ПРИОРИТЕТЫ шины данных CAN
Если несколько блоков управления одновременно начинают передавать сообщения, то вступает в силу « принцип приоритетности», согласно которому сообщение по шине данных CAN с наивысшим приоритетом будет передаваться первым без потери времени или битов (арбитраж доступа к шине данных) .
Каждый блок управления, утрачивающий право арбитража, автоматически переключается на приём и повторяет свою попытку отправить сообщение только после того, как шина данных CAN снова освободится.
Кроме пакетов данных существует также пакет запроса определённого сообщения по шине данных CAN. В этом случае блок управления, который может предоставить запрашиваемый пакет данных, реагирует на изданный запрос.
Для обработки данных в режиме реального времени должна быть обеспечена возможность их быстрой передачи. Это предполагает не только наличие линии с высокой физической скоростью передачи данных, но и требует также оперативного предоставления доступа к шине данных CAN, если нескольким блокам управления необходимо одновременно передать сообщения.
В целях разграничения передаваемых по шине данных CAN сообщений по степени срочности для отдельных сообщений предусмотрены различные приоритеты. Угол опережения зажигания, например, имеет очень высокий приоритет, значения пробуксовки — средний, а температура наружного воздуха — низший приоритет. Приоритет, с которым сообщение передаётся по шине данных CAN, определяет идентификатор (адрес) соответствующего сообщения.
Идентификатор, соответствующий меньшему двоичному числу, имеет более высокий приоритет, и наоборот (чем больше нулей в идентификаторе (битов нулевых) тем больше приоритет) . Протокол шины данных CAN основывается на двух логических состояниях: биты являются или «рецессивными» (логическая «1» — единица), или «доминантными» (логический «О» — ноль).
Если доминантный бит передаётся как минимум одним модулем шины, то рецессивные биты, передаваемые другими модулями, перезаписываются.
Для примера : Когда несколько блоков управления начинают одновременную передачу данных, то конфликт доступа к шине данных разрешается посредством «побитового арбитража запросов общего ресурса» с помощью соответствующих идентификаторов.
При передаче «поля идентификатора» блок-передатчик после каждого бита проверяет, обладает ли он ещё правом передачи, или уже другой блок управления передаёт по шине данных CAN сообщение с более высоким приоритетом. Если передаваемый первым блоком-передатчиком рецессивный бит перезаписывается доминантным битом другого блока- передатчика, то первый блок-передатчик утрачивает своё право передачи (арбитраж) и становится блоком-приёмником.
Первый блок управления (N 1) утрачивает арбитраж с 3-го бита.
Третий блок управления (N 3) утрачивает арбитраж с 7-го бита.
Второй блок управления (N 2) сохраняет право доступа к шине данных CAN и может передавать свое сообщение.
Другие блоки управления могут передавать свои сообщения по шине данных CAN только после того, как она освободится.
При этом право передачи опять будет предоставляться в соответствии с приоритетностью сообщения по шине данных CAN.
То есть, при использовании этого принципа «приоритетности», на шине данных CAN не должно происходить конфликта, если одновременно несколько устройств выставили различные логические уровни.
(на примере VW, Audi, Opel, Mercedes)
Шина CAN силового агрегата (быстрая шина), позволяющая передавать информацию со скоростью 500 кбит/с. Она служит для связи между блоками управления на линии двигателя и трансмиссии.
Шина CAN системы «Комфорт» (медленная шина), позволяющая передавать информацию со скоростью 100 кбит/с. Она служит для связи между блоками управления, входящими в систему «Комфорт».
Виды шин по классификации Mercedes:
Шина CAN-С – «быстрая» шина силового агрегата.
Шина CAN-B – «медленная», салонная шина «комфорт».
Шина CAN-D – диагностическая шина (используется для диагностики).
В автомобилях, имеющих диагностику по CAN шине, в качестве шлюза всех трёх шин установлен блок ZGW (центральный интерфейс). Это на более современных Мерседесах с 2002 года выпуска.
Цветовая маркировка шин на Mercedes
«Быстрая» шина силового агрегата (500 кб/сек) – зелёный и зелёный с белой полосой.
Шина «комфорт» — коричневый и коричневый с чёрной полосой.
На рисунках в различного рода руководствах и справочниках, провода шин CAN, для наглядности, могут быть обозначены приблизительно таким образом:
Общими для всех систем является следующее:
- Системы выполняют одинаковые предписания по передаче данных, сформулированные в соответствующем протоколе.
- Для передачи сигналов используются два скрученных между собой провода (Twisted Pair),которые эффективно противостоят внешним помехам (например, такая необходимость существует при их расположении в моторном отсеке).
Искал и нашел 12 вольт на медленной шине относительно кузова, откуда. Ведь в спецификациях написано 2,5 — 3,5 вольта?).
Области применения шины данных CAN
Для моторного отсека и салона применяются различные шинные системы CAN, которые отличаются друг от друга скоростью передачи данных.
Скорость передачи по шине данных CAN моторного отсека (CAN-С) составляет 500 Кбит/с, а шина данных CAN салона (CAN-B) вследствие меньшего количества особо срочных сообщений обладает гораздо меньшейскоростью передачи данных — 83 Кбит/с.
Обмен данными между обеими шинными системами осуществляется через так называемые «межсетевые шлюзы», т.е. блоки управления, подключенные к обеим шинам данных.
CAN-C (шина данных CAN моторного отсека)
В оконечном блоке управления с каждой стороны установлен так называемый согласующий резистор шины данных с сопротивлением 120 Ком, подключённый между обеими проводами шины данных.
Шина данных CAN моторного отсека активирована только при включенном зажигании.
CAN-B (шина данных CAN салона)
Некоторые блоки управления, подключённые к шине данных CAN салона, активируются независимо от включения зажигания (например, система центральной блокировки).
Поэтому шина данных салона должна находиться в режиме функциональной готовности даже при выключенном зажигании (то есть, возможность передачи пакетов данных должна быть обеспечена и при выключенном зажигании).
Для максимально возможного снижения энергопотребления в состоянии покоя шина данных CAN переходит в режим «пассивного ожидания» при отсутствии передаваемых пакетов данных и активируется снова только при последующем доступе к ней.
Если в режиме «пассивного ожидания» шины данных CAN салона какой-либо блок управления (например, потолочная блок-панель управления (N70) передаёт сообщение по шине данных CAN, то его принимает только ведущий системный модуль (например, блок управления EZS (N73)
Соответствующий ведущий блок управления сохраняет это сообщение в памяти и посылает сигнал активации («Wake-up») на все блоки управления, подключённые к шине данных CAN салона.
При выполнении активации блок управления (N73) проверяет наличие всех абонентов шины данных CAN, после чего передаёт сохранённое ранее в памяти сообщение.
Схема соединения шины CAN называется «топологией».
Или: «набор определенных правил, по которым к шине подключаются различные устройства».
Она зависит от модели конкретного автомобиля и Производителя.
Например, звездообразная топология запатентованная фирмой Daimler-Benz. Эта топология позволяет уменьшить резонансные проблемы в линии.
CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода CAN H и CAN L , по которым передаются сигналы при помощи специализированных ИМС приемо-передатчиков. Кроме того, ИМС приемо- передатчиков реализуют дополнительные сервисные функции:
- Регулировка скорости нарастания входного сигнала путем изменением тока на входе.
Встроенная схема ограничения тока защищает выходы передатчиков от повреждения при возможных замыканиях линий CAN_H и CAN_L с цепями питания , а также от кратковременного повышения напряжения на этих линиях.
Внутренняя тепловая защита.
Наиболее широкое распространение получили два типа приемоперадатчиков (трансиверов):
- «High Speed» приемопередатчики (ISO 11898-2),
Трансиверы, выполненные в соответствии со стандартом
«High-Speed» (ISO11898-2), наиболее просты, дешевы и дают возможность передавать данные со скоростью до 1 Мбит/c.
«Fault-Tolerant» приемопередатчики (не чувствительные к повреждениям на шине) позволяют построить высоконадежную малопотребляющую сеть со скоростями передачи данных не выше 125 кбит/c.
Теперь, когда мы немного ознакомились с понятием «шина данных CAN», можно коротко рассказать о том, как проводилась практическая работа по обнаружению и устранению неисправности шины данных CAN на автомобиле Mercedes ML350 рейстанлинговой модели.
Этот автомобиль попал в Россию из Америки, был привезен на продажу, дефект оказался непонятным и «плавающим»: «автомобиль может 15-20 минут работать нормально, а потом на панели загорается значок BAS ESP и отключается вся шина данных» .
Эти практические занятия проводились по учебному плану «Мастер-класс Mercedes» в компании BrainStorm, занятия проводил Дереновский Максим Васильевич (на фото вверху он слева: снимает разъем моторного блока) .
До этого момента автомобиль уже пытались ремонтировать в другой мастерской. Там поменяли «по показаниям» (?) блок BAS ESP, что не помогло устранить неисправность.
Тогда им посоветовали «прокинуть» два провода шины CAN минуя крыло автомобиля.
(Эта неисправность – гниение проводов на этом крыле и выход их из строя, является конструктивно-технологической недоработкой фирмы).
Тоже не помогло. И тогда автомобиль был доставлен на эти практические занятия с целью найти и устранить неисправность.
Для поиска неисправности применили два рекомендуемых метода:
- Проверка шины CAN по сопротивлению
Проверка по сопротивлениям
Шина представляет собой два провода витой пары.
Образно: «имеет начало и конец», которыми являются какие-либо два блока. В этих конечных блоках находятся согласующие сопротивления («терминаторы»,- разг.), номиналом 120 Ом.
- Если шина исправна и оконечные блоки подключены, то на шине мы увидим сопротивление 60 Ом (два по 120 в параллель).
Если есть обрыв на одном из конечных блоков — шина будет звониться 120 Ом, и более 120 Ом, если конечных блоков нет вообще.
Подключенные в параллель блоки мультиметром (по сопротивлению) не контролируются.
В ML350 один из конечных блоков будет моторный, второй, в зависимости от года выпуска, вероятнее всего AAM, EAM или EZS.
Определение КЗ (короткого замыкания) в шине данных CAN – определенно сложная задача. Как можно поступить:
- Визуально осмотреть провода с целью выявления и определения внешних повреждений
Расстыковать разъемы блоков управления и проверить, не погнуты ли контактные штифты в одном и втором разъеме, не попали ли туда посторонние предметы (грязь, кусочки проводов и т.д)
Одним из обучаемых было предложено начать проверку с отключения стеклоподъемников: «Он же на CAN «висит».
Неправильно. Стеклоподъемники «висят» на «медленной» шине и даже «если сильно захотят», все-равно «не положат «быструю» шину».
Начали отключать другие блоки по «быстрой» шине. Их достаточно много…
На блоке EGS (управление коробкой) , расположеный справа в ногах у водителя, было, как обычно, обнаружено масло.
Именно масло иногда является причиной неисправности этого блока.
Откуда оно там появляется – трудно сказать, но как вариант, — « согласно «эффекта каппилярности» масло из коробки поднимается по проводам и через неплотности уплотнений просачивается и на блок и вовнутрь его, привнося ошибку».
Эта ошибка конструктивная: некачественные уплотнения жгута проводов к соленоидам в коробке АКПП. По жгуту оно и поднимается в электронный блок.
Блок ААМ – тоже оказался исправным.
Кстати, если уж заговорили о нем:
- по причине «программного сбоя», у него часто «слетает» радиоканал ключей зажигания. После «перезаливки» блока работоспособность восстанавливается.
Виной «слёта» не только радиоканала , но и роллинга самих ключей , могут быть проблемы с питанием. Прокрутка двигателя на слабом аккумуляторе, плавная «посадка» АКБ на автомобиле , клеммы и т.д.
Но сама шина такой «слёт» не вызовет. Максимум сигнал разрешения запуска от блока ААМ не дойдёт до моторного и не будет включен даже стартер.
Отключение блоков тоже ничего не дало.
Проверили номера блока, которого заменили – все нормально, хотя тут тоже может быть путаница, так как существуют три варианта спецификаций для заказа:
Это достаточно важный момент, который нельзя упускать при проведении Диагностики.
Что такое «кодировки» для автомобиля:
Если просто, то это «единый язык, на котором блоки управления могут «разговаривать» между собой.
И так как автомобиль пришел из другой мастерской, а нам вообще неизвестна его история «жизни и ремонта», то проверять пришлось все кодировки.
И узнали, что в приборном щитке было прописано, что «BAS не интегрирован в ESP» .
Сделали наоборот – «BAS интегрирован в ESP», перезапустили систему управления и ошибка С1020 перестала появляться.
Какой можно сделать вывод : причиной неисправности С1020 на данном автомобиле явилась неправильно закодированная комплектация автомобиля.
Однако не стоит считать, что «ошибка по CAN» является простой и её можно быстро найти и быстро устранить.
Как говорят специалисты: «Это «головняк» и разобраться с ним можно только при отличном знании «психологии Mercedes».
Это на бумаге и в этой статье вся работа по определению неисправности уложилась в несколько строчек.
В жизни все намного труднее, сложнее и длиннее…
Информационный центр компании BrainStorm
Источник