Нет связи с ЭБУ тягача: CAN, адреса и диагностический ответ

Когда ЭБУ грузовика не выходит на связь, сначала важно определить, чего именно не удалось получить: корректного кадра, подтверждения приема, адреса блока или диагностического ответа. Эти результаты относятся к разным уровням обмена. Статья рассматривает проверяемую сеть, для которой CAN и J1939 уже подтверждены. Она не описывает все блоки, сети и поколения тягачей: общая поддержка J1939 не доказывает доступ ко всем функциям изготовителя. Источник

Сохраните в GruzHub результат попытки связи вместе с данными тягача и согласуйте с СТО, какой уровень обмена проверят следующим. В документе отделите полученное наблюдение от ещё открытого вопроса диагностики.

Сигнал есть — что это подтверждает?

CAN задает физический и канальный уровни обмена. Физический уровень относится к передаче сигнала, канальный — к сообщениям, которые контроллеры принимают как корректные. Протоколы более высокого уровня добавляют смысл. Поэтому электрическая активность, корректный кадр — отдельное сообщение сети — и понятное диагностическое содержание являются разными результатами. Наблюдение сигнала само по себе не устанавливает, что проверяемый ЭБУ ответил на нужный запрос. Источник

Сеть CAN широковещательная: узлы могут получать трафик, а локальные фильтры выбирают интересующие сообщения. Видимый обмен поэтому нельзя автоматически приписать одному определенному блоку. Для владельца разница практическая: «в сети передаются сообщения» еще не означает «контроллер двигателя ответил». Мастеру важно сохранить это различие при объяснении результата. Наличие других сообщений не закрывает вопрос о нужном ЭБУ; для такого вывода требуется отдельное основание. Эти положения рассматриваются для классического CAN, без переноса технических деталей на CAN FD. Источник

Физическое качество обмена также нельзя выразить одним результатом измерения. Согласование сети влияет на форму сигналов; ответвления и несоответствие импеданса — электрических свойств линии — могут создавать отражения. Измерение сопротивления и исследование осциллограммы, то есть формы сигнала, отвечают на разные вопросы. Если проверено сопротивление, получен результат именно этой проверки. Он не заменяет оценки формы сигнала и не подтверждает работоспособность всех узлов. Источник

Поэтому заключение «сопротивление проверили, вся связь исправна» шире имеющегося доказательства. Обратная подмена также мешает: наблюдение формы сигнала не становится подтверждением всех диагностических функций. Для владельца полезно понимать, какое свойство сети действительно исследовали; для мастера — объяснить предел результата, не превращая его в диагноз блока. Пример Kvaser относится к определенной сети CAN/CAN FD и интерфейсу D-sub. Его контакты, измерительные напряжения и сопротивления нельзя переносить на любой разъем тягача. Эта справка не задает универсальной распиновки или нормы измерений: применимость конкретной проверки должна соответствовать исполнению автомобиля. Источник

Почему ACK не является ответом нужного блока?

Кадр данных CAN содержит идентификатор, данные, контрольное значение CRC и подтверждение ACK. Последнее означает корректный приём одним или несколькими контроллерами, но не подтверждает обработку запроса нужным получателем. Например, в одном условном наблюдении подтверждён только ACK; в другом дополнительно получен диагностический ответ. Это разные результаты, и ни один сам по себе не удостоверяет исправность двигателя или тормоза. Источник

Ошибка обмена и код двигателя — разные события

CAN-контроллеры обнаруживают ошибки сообщений, ведут счетчики приема и передачи и ограничивают участие проблемного узла. Контроль битов, структуры, подтверждения и CRC относится к сообщению. Диагностический код двигателя имеет другой предмет: его нельзя приравнять к ошибке передачи. Поэтому наличие кода не означает, что содержащий его кадр поврежден. И наоборот, ошибка сообщения не раскрывает автоматически неисправность двигателя. Для заключения важно назвать, какой именно результат получен: ошибка обмена либо диагностические сведения. Источник

ErrorPassive и BusOff — разные состояния CAN-контроллера. В BusOff узел не участвует в трафике, однако название состояния не устанавливает причину. Подтверждение BusOff поэтому нельзя сразу переводить в решение о замене ЭБУ. Также нельзя объявлять это состояние только потому, что инструмент не получил связи. Здесь существуют три отдельных вопроса: наблюдается ли обмен, установлено ли состояние контроллера и известна ли причина. Источник

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

Условное сопоставление. В варианте А отмечено переполнение буфера драйвера или интерфейса: пробел может означать потерю данных записи, а не прекращение работы ЭБУ. В варианте Б такого признака нет, но причина отсутствия нужного сообщения все равно не установлена. Не все интерфейсы различают аппаратное и программное переполнение. Разъем, провод, согласование и неподходящая скорость другого узла — возможные направления проверки конкретной конфигурации, а не установленный виновник. Сопоставление показывает разницу доказательств, без вымышленного результата ремонта. Источник

Пассивная запись не равна активной диагностике

В рассматриваемом Kvaser логгере SilentMode — режим пассивного наблюдения — не передает данные, ACK или кадры ошибок. Такая запись показывает наблюдаемый обмен, но не подтверждает, что инструмент инициировал диагностическую услугу и получил ответ. Поэтому фразы «сняли запись сети» и «выполнили активный диагностический обмен» описывают разные действия. Само слово «подключен» не объясняет, какую роль выполнял инструмент и какое доказательство получено. Источник

Это различие помогает понять результат без лишнего вывода об ЭБУ. Если инструмент только наблюдал сообщения, его запись следует оценивать как наблюдение. Отсутствие в ней специально запрошенного ответа нельзя представлять как результат активного сеанса, который не подтвержден. В источнике отдельно рассмотрено стендовое соединение с одиночным узлом, где значимо наличие второго активного участника. Этот пример объясняет роль наблюдателя в указанной конфигурации. Он не дает универсальной процедуры восстановления связи и не служит рекомендацией переключать режим сканера на подключенном автомобиле. Сравнивать результаты следует с учетом того, наблюдал инструмент или участвовал в обмене. Источник

Почему DM1 бывает виден без полного сеанса?

В подтвержденной сети J1939 сообщение DM1 передает активные коды вне специально инициированной услуги диагностического инструмента. Его могут передавать ЭБУ, поддерживающие диагностику J1939. Поэтому код может присутствовать в записи, хотя успешный адресный диагностический сеанс не установлен. Противоречия здесь нет: получено передаваемое узлом диагностическое сообщение, а результат отдельного запроса остается другим вопросом. Утверждение «код прочитан» нужно оценивать в пределах того обмена, который действительно наблюдали. Источник

Источник сообщения позволяет связать код с сетевым узлом. Это конкретнее, чем просто наличие трафика, но не доказывает доступ ко всем функциям контроллера. Владельцу можно объяснить результат словами: «От этого источника получено сообщение с активными кодами». Формулировка «вся диагностика блока работает» потребует других подтверждений. Также DM1 не дает универсального разрешения продолжать движение по цвету лампы. Действия определяются требованиями изготовителя конкретного автомобиля. Источник

Прием сообщения нужно отличать и от применимой расшифровки. SPN обозначает определенный параметр или сигнал: физическую величину, состояние либо команду. Для интерпретации нужны сведения о содержимом, длине, преобразовании и допустимой области. Поэтому «данные получены» и «данные правильно истолкованы для этой задачи» — разные утверждения. Факт приема не восполняет отсутствующее описание параметра. Источник

Почему отдельный кадр не всегда является полным сообщением?

В рассматриваемом J1939 длина группы параметров может превышать полезную нагрузку одного классического CAN-кадра. Тогда отправитель разделяет данные на отдельные пакеты, а получатель собирает их в исходном порядке. Для этого используется транспортный протокол. Поэтому запись одного корректного кадра и наличие полной группы параметров — разные результаты: кусок передачи нельзя выдавать за законченный ответ. Это относится к описанному классическому обмену J1939, а не к произвольному протоколу любой сети тягача. Источник

Управление потоком тоже различается. В соединении между определёнными участниками получатель может влиять на передачу отдельных пакетов; соединение может быть прервано. При широковещательной передаче BAM потоком управляет отправитель, а получатель, пропустивший сообщение, не сигнализирует об этом в рамках такого обмена. Для интерпретации записи важно различить эти варианты, прежде чем считать отсутствие подтверждения одним и тем же отказом. Нельзя переносить поведение адресного соединения на любой широковещательный поток. Источник

В транспортном обмене предусмотрены собственные управляющие сообщения. В адресном транспортном обмене EomACK подтверждает полный приём сообщения из нескольких пакетов; это другое подтверждение, чем ACK отдельного CAN-кадра. Название ACK в двух местах не означает одинакового предмета проверки. Например, документ, в котором указано подтверждение приёма кадра, ещё не сообщает о завершённой сборке всех пакетов. В профессиональном заключении следует различать наблюдаемый кадр, собранное сообщение и ответ на прикладную задачу. Здесь объясняется смысл результата, а не предлагается отправлять управляющие сообщения в автомобиль. Источник

Найденный адрес еще не проверяет функции

Управление сетью J1939 относится к допуску к обмену и учету адресов. Его не следует понимать как обычное автомобильное управление сном подсети. Сообщение Address Claim перед основным обменом раскрывает NAME — сетевую идентификационную характеристику узла — и адрес. Адреса не должны дублироваться, поэтому конфликт требуется разрешить. Обнаружение узла в таком обмене подтверждает присутствие на этом уровне; оно не является проверкой всех функций контроллера. Источник

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

Это существенно для причинного вывода. Установленный конфликт и ожидаемая реакция контроллера — отдельные сведения. Само наблюдение конфликта не сообщает, какой вариант конфигурации реализован, а знание общего механизма сравнения NAME не заменяет данных об исполнении. Поэтому обещание автоматического разрешения ситуации может оказаться шире подтвержденных возможностей блока. В разговоре с владельцем достаточно разделить два результата: конфликт установлен; дальнейшее поведение требует подтверждения для этого узла. Описанные различия не являются процедурой изменения адресов или программирования контроллеров. Их назначение — объяснить, почему одинаковое наблюдение нельзя одинаково продолжить для любого блока. Источник

J1939 Request может запрашивать сообщение Address Claimed. При этом правила начального обмена отличаются от передачи данных с действительным адресом. Ответ на обнаружение поэтому нужно отличать от ответа на главный прикладной вопрос. Успешное обнаружение относится к соответствующему обмену, а не ко всем последующим проверкам. Если инструмент показывает найденный узел, результат следует понимать в этих пределах: установлен участник обнаружения, но нужная диагностическая функция еще не подтверждена этим фактом. Источник

Пустой или неполный список блоков также не является схемой реально установленных компонентов. Он описывает результат обнаружения. Отсутствие строки в перечне нельзя сразу переводить в утверждение о физическом отсутствии компонента. Для владельца точная формулировка звучит так: «В этом результате обнаружения блок не представлен». Она сохраняет фактический результат, не добавляя недоказанного объяснения. Для мастера остается различие между составом конкретного автомобиля и ответами, полученными при обнаружении. Оно важно даже тогда, когда список выглядит завершенным: полнота перечня и подтверждение прикладной функции являются разными вопросами. Источник

Диагностический ответ: пределы общего протокола

J1939 базируется на CAN и добавляет адресацию, группы параметров и диагностические сообщения. Однако стандарт допускает собственные сообщения производителей. Поэтому корректный CAN-кадр не обязательно расшифровывается универсальной базой. Положительный результат нижнего уровня не восполняет отсутствующее описание содержания. Общую поддержку J1939 нельзя расширять до обещания всех функций изготовителя; конкретные скорости, распиновку и производственные процедуры также нельзя переносить на все тягачи. Источник

Наличие универсального адаптера не доказывает готовность к диагностике изготовителя. Вопрос к результату должен быть предметным: какая функция проверена и какой ответ получен? Ответ по одной задаче нельзя расширять до утверждения о доступности всех функций. Это ограничение сохраняется даже при наличии корректных сообщений и найденного адреса. Источник

Для владельца смысл профессионального заключения заключается в границах выполненной проверки. «Инструмент поддерживает протокол» сообщает о заявленной возможности; «получен ответ на эту проверку» описывает результат. Между ними нельзя ставить знак равенства только по наличию адаптера. Мастеру полезно связывать заключение с конкретной доступной функцией, не обещая увидеть все сети и блоки тягача одним инструментом. Прикладной ответ добавляет доказательство по запрошенной задаче, но не превращается в проверку остальных возможностей контроллера. Поэтому положительный результат следует объяснять столь же точно, как отсутствие ответа. Источник

Краткий модельный пример дает бюллетень MAN KSM 71302, Supplement 5 от 12 ноября 2013 года. На странице 6 различены A302 — центральный бортовой компьютер ZBR, A100 — центральная электрическая система и A312 — KSM. Применимость KSM Step 2 и ZBR step 7.2+ ограничена условиями бюллетеня. Пример показывает необходимость схемы своего исполнения для понимания пути обмена. Он не является универсальной схемой MAN TGX/TGS и не доказывает наличие шлюза или дефекта каждого тягача. Из него нельзя вывести диагноз всей модели. Источник

Смежные материалы: Ошибка ABS грузовика: датчик скорости, проводка и модулятор, Foton Auman не заводится: ошибки CAN двигателя, КПП и SCR.

Частые вопросы

Почему ACK не означает, что ЭБУ исправен?

ACK подтверждает приём кадра участником CAN. Это не заключение об исправности двигателя и не подтверждение ответа нужного блока. Источник

Можно ли любой узел заставить автоматически сменить адрес?

Поведение при конфликте зависит от конфигурации узла. Автоматический поиск нового адреса не предусмотрен для любого исполнения. Источник

Равен ли EomACK подтверждению отдельного CAN-кадра?

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

Источники

• Kvaser: уровни CAN
• Kvaser: кадры CAN
• Kvaser: ошибки CAN
• Kvaser: состояние контроллера
• Kvaser: согласование сети
• Kvaser: режим регистрации
• Vector: протокол J1939
• Vector: DM1
• Vector: SPN
• Vector: доступ к сети
• Vector: конфликт адресов
• Vector: динамическая сеть
• Vector: свойства J1939
• MAN: KSM 71302, Supplement 5, 12.11.2013
• Vector: фрагменты сообщения
• Vector: варианты транспортного обмена
• Vector: завершение сообщения