Исправление отсутствующих блока KOMBI в дереве ЭБУ

     Владельцы китайской приборной панели и кто хоть раз диагностировал свой автомобиль, знают что в дереве ЭБУ вы видите что блок KOMBI не выходит на связь.  Например как на моем авто:

ISTA


 KOMBI  - это наша замененная приборка;

 CID  - у меня также вместо экрана установлен Android. Хорошо описано на форуме;

 CIC  - не видит дисплея. (сразу скажу что эту проблему не исследовал. Думаю она лечится эмуляцией LVDS подключения между CIC и экраном CID. Может изучу этот момент позже для "зеленого" дерева).

 RDC  - это никак не соберусь заменить датчики в шинах;


    Вроде бы само по себе отсутствие блоков ничего страшного в себе не несет, но глаз режет. И это еще затягивает время процесса "Проверка а/м (Чтение информации о блоках управления)" в ISTA.

    Было принято решение попробовать выполнить мероприятия по озеленению деревьев 😀

    Глубоких знаний по протоколу диагностики в начале процесса не было. Понимал что по шине D-CAN диагностический прибор (K+D-CAN кабель или ICOM, или Launcher) опрашивает блоки и в итоге понимает кто в каком состоянии находится и визуализирует это. Значит нам нужно разобрать этот диагностический протокол и понять чем отвечают штатные приборки и CID диагностике. А затем понять, сможем ли мы с этими собранныеми данные как-то работать. И да, как и в предыдущих экспериментах одно условие - никакого паяльника и доп. устройств.

    При таких условиях задачи решение только одно - это интегрировать код диагностики в существующую прошивку MCU. 

    Собрал стенд:

  • оригинальная приборка
  • оригинальный CID
  • TJA1055 трансивер для K-CAN (100kbit/s)
  • STM32 blue pill для дампа эфира и сопутствующих вещей. Для дампа также использовал одноплатник с CAN шиной и Linux-ом на борту.
  • макетная плата STM32F105VCT6 (как и на китайской приборке) - MCU
  • К+D-CAN кабель + ISTA - откуда собственно и будем опрашивать

    Первое что сразу понял - это то что такого набора недостаточно. У E-серий BMW есть как минимум три шины CAN: 

  • K-CAN (Body CAN, 100 кбит/с): Отвечает за кузовную электронику (климат-контроль, PDC, сиденья, освещение FRM, приборную панель KOMBI).
  • PT-CAN (Powertrain CAN, 500 кбит/с): Связывает блоки силового агрегата и ходовой части (DME/DDE, EGS, DSC, EKP, VTG, ACSM/MRS).
  • D-CAN (Diagnostic CAN, 500 кбит/с): Используется для диагностики на машинах начиная с 03/2007.

        Это я видел когда-то на бумаге,  а теперь мне нужно было понять как мне из D-CAN где работает ISTA опросить блок KOMBI, который живет на K-CAN. Скорости шин разные, хотя диагностические сообщения передаются у них одинаково. В моем авто за маршрутизацию между шинами отвечает JBE. Он транслирует сообщения и пакетирует данные между шинами PT-CAN, K-CAN и D-CAN. Именно с этого блока выведен D-CAN на OBD2. У меня конечно такого шлюза под рукой не было. Тогда я взял трансивер на базе TJA1050 и еще одну bluepill для терминации D-CAN, а с первой bluepill я связал по UART (одной не обошелся так как у STM32F103 только один CAN). Написал перекладку между шинами (процесс был небыстрый) и увидел первые долгожданные запросы от ISTA при попытке "Считать данные т/с". Увидел я кадры именно на K-CAN шине, значит самодельный шлюз работает:


     Да, я увидел опрос блоков с интервалом в одну секунду. 

CAN-ID 0x6F1 - это адрес тестера(в данном случае ISTA), 

8-длина данных CAN сообщения

10, 40, 70, 72, 40, 00 - это диагностические адреса блоков 

дальше дина и данные UDS сообщения. 

    Почему именно эти блоки опрашиваются? Изучив этот вопрос я ответил - Да потому что в CAS(0x40) и FRM(0x72) лежит комплектация автомобиля, на базе которой строится дерево ЭБУ и ISTA берёт из заказа авто (Fahrzeugauftrag, FA) и далее по этому дереву ведется опрос уже конкретных блоков. И мне надо как-то ответить на эти сообщения чтобы ISTA продолжила опрос и опросила мои KOMBI и CID. Дальше я бы сдампил ответ блоков и уже эти данные были бы основой для моего поддельного ответа в MCU. 

    Был вечер и идти в машину дампить CAN совсем не хотелось. Открыл логи ISTA с предыдущей какой-то диагностики и нашел нужный мне Fahrzeugauftrag и дальше ответ явно в hex. Я если честно ожидал увидеть что-то типа текстового как я это вижу например в том же NCSExpert. 


    Пошел разбирать. 02 - тип кодирования данных и дальше пошли 6 битовые значения. Детально не буду тут разбирать, но в итоге вытягивается комплектация заказа авто. ISTA видит эти данные может восстановить какие блоки в этой комплектации и уже конкретно их опростить.

    Чтобы на стенде своем опросить мне нужно ответить CAS-ом и FRM. Это было реализовано на bluepill. Из нюансов - это если ответ не влезает в один кадр (8-1(id блока)-1(длина) = 6 быйт), то предусмотрен многокадровый обмен. Не буду тут глубоко погружаться в детали, механизм неплохо описан в этом посте.

    В итоге эмулятор базовых ответов CAN и FRM был реализован и ISTA пошла опрашивать уже блоки по дереву и добралась до моих 0x60(KOMBI) и 0x73(CID) и эти ребята ответили как положено.

    Один из важных ответов 1A 80, именно из него берутся индексы, по которым определяется конкретный вариант блока.


используя индексы находится SGBD блока. Так наша ISTA узнаёт не «на 0x60 что-то есть», а «здесь стоит komb70 такой-то ревизии».

    Ответ на 1A 86  содержит VIN

    Ответа 21 0B — одометр



    Ответ 23 12 у CID

     получается что блок CID не привязан к машине и заменяемый без кодирования.


    В итоге я получил структуру ответов моих боков KOMBI и CID диагностике.



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

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

    В итоге я получаю прошивку MCU. Сначала пробую прошить на стенде. С первого раза естественно ничего не заработало. После нескольких подходов прошивка запустилась. Протестировал ISTA на стенде и пошел шить в машину.

 До этого была установлена прошивка с фиксом 100км одометра

С блоками без связи


    Шьем на пропатченну (я специально изменил дату, чтобы не запутаться где какая)



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




И как результат в списке ошибок нет KOMBI и CID и зеленое дерево (с желтыми тоже будем бороться):





Поставленная задача выполнена! 

Но сразу оговорюсь, что прошивка не универсальная, т.к. содержит данные от конкретно моего автомобиля. Иначе бы ISTA выплюнула бы блок увидев что на ней VIN и индексы другие. Похоже я поторопился и VIN не участвует в анализе здоровья блока в дереве ЭБУ. Достаточно только DiaI в пакете IDENT (1A 80), а это значение общее для всей линейки блока. Т.е. можно получить более-менее универсальную прошивку, только с разными ветками по CID/CIDR.
                    

PS: --------------------------------------------------------------------------------------------------------------------
    Следующим этапом у меня идея почти реализована, но правило "делаем все без паяльника и внешних устройств" для этого проекта разбилось о стену блока JBE, который не маршрутизирует диагностические кадры из K-CAN в PT-CAN. Если ничего не придумаю, то придется делать шлюз между этими шинами (он у меня реализован на двух bluepill, но в машину такое не поставишь. Нужно что-то на базе auto industrial схематехнике). Ну или забросить идею. Но забрасывал несколько раз идеи с ошибками в дереве ЭБУ  и одометром, но в конечном итоге закончил с ними. Посмотрим что будет с этой.

    Вот текущие наброски: вставляешь флэшку, запускается диагностика. Определяет блоки, считывает/удаляет ошибки, выполняет job-ы из SGDB. Вынимаешь флешку - переключается в штатный интерфейс.

красные блоки почти все - это PT-CAN




    Ну т.е. диагностика всегда под рукой без кабелей и диагностических приборов. Только флешка. 


Спасибо за внимание.





Комментарии

Популярные сообщения из этого блога

Проблема фиксированного 100км одометра в диагностике