Анализ проприетарного протокола K-линии на примере блока SRS Honda CR-V 3

Довольно часто мы сталкиваемся с ремонтом блоков управления SRS от Honda. В большинстве случаев ремонт заканчивается заменой регулятора питания. На YouTube опубликовано видео, где подробно показан процесс такого ремонта. Обычно после замены регулятора связь с ЭБУ восстанавливается. Однако поломки могут быть разными по сложности: например, блок, который у нас на столе в данный момент, даже после замены регулятора питания не вышел на связь. Направление поиска решения этой задачи мы определили, но этот процесс заслуживает отдельного внимания и, возможно, будет освещён в будущем в виде новой статьи.

Несколько лет назад к нам поступил ЭБУ SRS от HONDA CR-V III с ошибкой (DTC) 53-85. По какой-то непонятной причине диагностический комплекс определяет эту ошибку как незначительную, помещая в конец списка; однако на самом деле данная неисправность для блока управления фатальна.

Диагностические сканеры Honda выводят всего три ошибки, несмотря на то что фактически их может быть значительно больше. В большинстве случаев такая схема диагностики подходит, и пользователи обычно не обращают внимания на это обстоятельство, но данный нюанс создал значительные трудности для нас. В связи с особенностью функции (DTC) у Honda — выводить одновременно только три ошибки — код 53-85 становится невидимым при запуске блока без периферии, поскольку в нашей лаборатории все ремонты и исследования проводятся на столе. Для решения подобных проблем было принято решение собрать стенд, практически полностью воспроизводящий всю периферию автомобиля: от приборной панели до имитации двигателя и коробки передач. Получился симулятор, создающий видимость реального автомобиля Honda для диагностики системы пассивной безопасности. Тогда это позволило нам эффективно выявить ошибку, поработать с ней и научиться устранять её.

Стенд не потерял актуальность и по сей день. Но в связи с ограниченностью диагностических сканеров, или назовём это «особенность», у нас появилось цель научиться считывать все ошибки (DTC) из блока управления одним списком, не для замены уже созданного инструментария, а как дополнительный вектор развития наших возможностей.

Сканеры не только выдают ограниченную информацию, но и считывают неправильные идентификаторы и данные, например, автосканер Launch определяет ECU ID:

На самом деле ID блока управления другой:

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

В начале реализации задуманного понадобилось средство для захвата и анализа трафика. Здесь пригодились инструменты, разработанные ранее: в частности, K-Line logger, созданный несколько лет назад с использованием интерфейса OpenPort 2.0. Логгером отсканировали протокол диагностики. Затем написали программу, реализующую этот протокол на базе API J2534.

При первом подключении к ЭБУ связь модуля с блоком управления установить не удалось. Последующее осциллографическое исследование показало,что сценарий пробуждения (WuP) блока управления Honda отличается от стандартного протокола ISO 9141, который был задан нашему модулю по умолчанию.

В сети мы нашли ресурс, на котором выложена информация о том, что Honda использует собственный проприетарный протокол KEIHIN, и его описание. Openport 2.0 позволяет программировать нужные нам параметры, благодаря этому мы смогли адаптировать оборудование для нашей цели.

// set timing, honda specific parameters   SCONFIG_LIST scl;   SCONFIG scp[4] = {{P1_MAX, 0}, {PARITY, 0}, {TWUP, 50}, {TINIL, 25}};   scl.NumOfParams = 4;   scp[0].Value = timeout * 2;   scp[1].Value = parity;   scp[2].Value = HONDA_PROPRIETARY_TWUP;   scp[3].Value = HONDA_PROPRIETARY_TINIL;   scl.ConfigPtr = scp;   if (j2534.PassThruIoctl(chanID, SET_CONFIG, &scl, NULL)) {     reportJ2534Error();   }

Подключившись к ЭБУ, мы приступили к тестированию модуля. Начать решили с перебора запроса с командой 60h (запрос считывания). Запрос состоит из нескольких частей: заголовок (команда); количество байт, включая контрольную сумму; параметр команды (обычно два байта) и контрольная сумма. В итоге общая структура составляет пять байт.
Пример нашего запроса выглядит следующим образом: 60h (команда), 05h (количество
байт), 70h, 02h (параметр команды), 29h (контрольная сумма). Контрольную сумму можно рассчитать по алгоритму полученному из источника.

Перебирая последний байт параметра команды, мы отметили, что изменяется длина строки ответа. Это позволило понять, что второй байт указывает на длину данных, которые мы хотим получить. Например, если указать 02h, то система вернет два байта, если 03h — три байта и так далее. Максимальное значение, которое принимает система 0Fh. После достижения этого значения дальнейший рост длины строки не происходит.

Проверку работоспособности нашего модуля мы начали с поиска Key ID, перебором нашли серийные номера, нашли номер блока.

Далее проводились эксперименты с извлечением информации об ошибках. Ошибки запрашиваются с помощью трёх параметров команды 60h: 08h, 0Ah и 0Ch. Эти параметры позволяют получить три ошибки. Однако возникает вопрос: почему нельзя использовать один для получения информации о всех сохранённых ошибках ЭБУ ?

Приступили к анализу информации о сохранённых ошибках, выяснилось, что они лежат в 16-байтовых блоках. Всего этих блоков шестнадцать. После анализа блоков обнаружили следующее:
— некоторые возвращают только (DTC);
— другие — исключительно данные;
— третьи содержат идентификаторы.

Таким образом, мы выяснили, что ошибки можно считывать одной командой. Запрашивая 16 байт, в пятом байте находится первая ошибка, в седьмом – вторая, третья хранится отдельно. Эти ошибки также сохраняются в EEPROM, где хранятся те же самые идентификаторы.

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

Подобно работе с запросом 60h, мы перебрали запрос с командой 61h (команда действия). Автомобиль, блок SRS которого мы тестировали с нашим оборудованием, попал в аварию, и, соответственно, в ЭБУ был прописан краш. После перебора параметров команды 61h блок управления был восстановлен.

 Краш, как его называют в кругах специалистов или Crash Data -это пакет информации о том, что произошло с автомобилем в момент ДТП. В связи с этой информацией в память блока SRS прописываются данные, нестираемые стандартными методами и сканерами. По правилам большинства компаний, производящих автомобили, такой блок приходит в негодность и требует замены. На основании полученных нами данных в сканер была добавлена функция по удалению информации об аварии.

 P.S. В случае, когда в системе прописана краш-дата, после срабатывания подушек безопасности, сканер выводит на экран четыре ошибки (DTC). Crash Data запрашивается сканером отдельной командой и выводится на экран при её наличии в ECU SRS.