JLR Pathfinder Offline

[K1R]

Обращайте внимание на наличие строк "DSFMService - No assembly part number found for <Название блока>, keeping <Версия прошивки>" в лог-файле. Это говорит о том, что софт блока имеет более новую версию, чем поддерживается PF. Это означает, что функционал работы с этим блоком будет ограничен. Если блок, в который загружается конфиг, имеет более новую версию, то загрузить конфиг в такой блок также не получится. Как минимум без патча PF.

Все эти дни я пытался понять, почему в процессе работы нашего пафа в логе feedback.log были сообщения "DSFMService - No assembly part number found for", а в китайском — нет, и насколько критичны такие ошибки. Самое интересное, что спустя несколько дней вышло наоборот: в нашем пафе не было таких ошибок, а в китайском для некоторых модулей они появились.

Если кратко, то сообщения "DSFMService - No assembly part number found for" не говорят напрямую о том, что софт блока имеет более новую версию, чем поддерживается PF. Изучив кучу логов перед этими сообщениями, я понял, что в моём случае они возникали, когда не было связи с ECU-блоком (адаптер не распознавался / шнурок от адаптера отвалился в процессе работы и т.д.), и паф не смог получить из него информацию через UDS-команды.

А вот сообщения "ECUAssemblyNumber_Non_Released" больше похожи на то, что паф ничего не знает об установленной версии ПО в блоках. Далее — подробный разбор. Для контекста: у меня L550 2020, DOIP.

Для начала надо понять, как паф узнаёт о версиях ПО в блоках. Когда происходит автоскан, паф отправляет в каждый модуль UDS-команды для получения информации о версиях ПО, VIN, серийном номере и т.д. Вот пример такого взаимодействия с блоком BCM:

10.01.2026 17:44:06,361 console - SendRaw BCM: 22 F1 12
10.01.2026 17:44:06,457 console - Raw Answer BCM: 62 F1 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 17:44:06,457 console - SendRaw BCM: 22 F1 13
10.01.2026 17:44:06,572 console - Raw Answer BCM: 62 F1 13 4A 50 4C 41 2D 31 34 46 30 34 31 2D 42 47 00 00 00 00 00 00 00 00 00 00
10.01.2026 17:44:06,576 console - SendRaw BCM: 22 F1 11
10.01.2026 17:44:06,658 console - Raw Answer BCM: 62 F1 11 4A 50 4C 41 2D 31 34 43 32 35 36 2D 42 47 00 00 00 00 00 00 00 00 00 00
10.01.2026 17:44:06,658 console - SendRaw BCM: 22 F1 88
10.01.2026 17:44:06,730 console - Raw Answer BCM: 62 F1 88 4C 50 4C 41 2D 31 34 43 31 38 34 2D 41 44 00 00 00 00 00 00 00 00 00 00
10.01.2026 17:44:06,730 console - SendRaw BCM: 22 F1 24
10.01.2026 17:44:06,819 console - Raw Answer BCM: 62 F1 24 4C 4B 37 32 2D 31 34 43 31 38 35 2D 41 41 00 00 00 00 00 00 00 00 00 00
10.01.2026 17:44:06,819 console - SendRaw BCM: 22 F1 08
10.01.2026 17:44:06,922 console - Raw Answer BCM: 62 F1 08 4C 50 4C 41 2D 31 34 43 34 30 38 2D 41 41 00 00 00 00 00 00 00 00 00 00

Тут всё просто: запрос начинается с 22, а дальше указывается DID, ответ, соответственно, начинается с 62 + DID.
Изучив различные файлы пафа, я нашёл список DID, специфичный для JLR. Итого, просто переведя ответы от модуля из hex-значений и сопоставив DID, получаем такую таблицу данных для модуля BCM:

| DID | Значение (ASCII) | Назначение (типичное) |
| ---- | ---------------- | ---------------------------------------- |
| F112 | пусто | ECU Assembly Number |
| F113 | JPLA-14F041-BG | ECU Delivery Assembly Number |
| F111 | JPLA-14C256-BG | ECU Core Assembly Number |
| F188 | LPLA-14C184-AD | Vehicle Manufacturer ECU Software Number |
| F124 | LK72-14C185-AA | ECU Calibration Data #1 Number |
| F108 | LPLA-14C408-AA | ECU Network Signal Calibration Number |

Это те самые значения, которые показывает интерфейс пафа, за исключением главного — основной версии прошивки блока BCM, в нашем случае LK72-14B476-AR. Сами блоки не выдают эту информацию через UDS-команды (DID F112), отвечая нулями на этот запрос.
Поэтому тут вступает логика пафа: получив информацию о версии железа, калибровок и прочего напрямую из блока, он сам вычисляет основную версию ПО блока по файлам ivs.

Вот, к примеру, сокращённое содержимое файла LK72-14B476-AR (основная версия блока). В нём описано, что прошивка по факту состоит из 4 файлов (Strategy, Secondary Bootloader, Calibration, Signal Configuration), а также указано, какие версии были до и какие версии есть после:

<?xml ?><ivs:eCUAcronym="BCM" assyPN="LK72-14B476-AR" asDeliveredPID="F112" predecessorPartNumber="LK72-14B476-AP" successorPartNumber="LK72-14B476-AS">
<hardwareComponentPart hardwareType="JPLA-14C256-BH" predecessorPartNumber="JPLA-14C256-BG" successorPartNumber="JPLA-14C256-BJ" filePNPid="F111"/>
<node nodeAddr="1726">
<softwareComponentPart partType="Strategy" filePN="LPLA-14C184-AD" successorPartNumber="LPLA-14C184-AE" predecessorPartNumber="LPLA-14C184-AC" filePNPid="F188">
<supportingSoftwarePart partType="Secondary Bootloader" filePN="JPLA-14C187-AA">
</supportingSoftwarePart>
</softwareComponentPart>
<softwareComponentPart partType="Calibration" filePN="LK72-14C185-AA" filePNPid="F124">
</softwareComponentPart>
<softwareComponentPart partType="Signal Configuration" filePN="LPLA-14C408-AA" filePNPid="F108">
</softwareComponentPart>
</node>
</ivsartLineageType>

Сводная таблица: 3 значения этих файлов полностью совпадают с полученными из блока, 1 значение было в предыдущей версии и одно не описано в XML.

| DID | Значение в BCM | Ожидание XML | Статус |
| ---- | -------------- | -------------- | -------------- |
| F111 | JPLA-14C256-BG | JPLA-14C256-BH | predecessor |
| F188 | LPLA-14C184-AD | LPLA-14C184-AD | |
| F124 | LK72-14C185-AA | LK72-14C185-AA | |
| F108 | LPLA-14C408-AA | LPLA-14C408-AA | |
| F113 | JPLA-14F041-BG | — | не описан |

На основе этого паф определяет, что основная версия ПО блока BCM — LK72-14B476-AR, о чём и пишет в логе сразу после UDS-команд:

10.01.2026 17:44:07,277 console - errorLog(message: ##! CHECKED LK72-14B476-AR, InIvsForSelectedSeries = true
10.01.2026 17:44:07,539 console - Setting assembly part number to: LK72-14B476-AR for domain Body Control Module [BCM] [3018]
10.01.2026 17:44:21,141 console - Identified ECU: BCM_L462_2018_00_V1
10.01.2026 17:44:21,141 console - <-- AREA SCAN Body Control Module [BCM] [3018] END --

А теперь рассмотрим сценарий (ошибка ECUAssemblyNumber_Non_Released), когда паф, после того как получил данные из блока, не может вычислить основную версию ПО по причине либо того, что ПО действительно новее, чем у него есть в ivs, либо, как в моём случае, версии файлов (Strategy, Secondary Bootloader, Calibration, Signal Configuration) неконсистентны.

Модуль TCU — паф стандартно запрашивает версии:

10.01.2026 18:22:46,370 console - SendRaw TCU: 22 F1 11
10.01.2026 18:22:46,420 console - Raw Answer TCU: 62 F1 11 4A 38 41 32 2D 37 30 37 31 39 2D 43 47 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,420 console - SendRaw TCU: 22 F1 20
10.01.2026 18:22:46,500 console - Raw Answer TCU: 62 F1 20 4A 38 41 32 2D 37 30 37 31 32 2D 42 41 41 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,500 console - SendRaw TCU: 22 F1 23
10.01.2026 18:22:46,583 console - Raw Answer TCU: 62 F1 23 4A 38 41 32 2D 37 30 37 31 32 2D 47 4B 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,583 console - SendRaw TCU: 22 F1 21
10.01.2026 18:22:46,682 console - Raw Answer TCU: 62 F1 21 4A 38 41 32 2D 37 30 37 31 32 2D 43 5A 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,682 console - SendRaw TCU: 22 F1 22
10.01.2026 18:22:46,743 console - Raw Answer TCU: 62 F1 22 4A 38 41 32 2D 37 30 37 31 32 2D 46 59 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,743 console - SendRaw TCU: 22 F1 88
10.01.2026 18:22:46,803 console - Raw Answer TCU: 62 F1 88 4A 38 41 32 2D 37 30 37 31 32 2D 41 41 41 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,803 console - SendRaw TCU: 22 F1 25
10.01.2026 18:22:46,862 console - Raw Answer TCU: 62 F1 25 4A 37 41 33 2D 37 30 37 31 33 2D 53 48 00 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,862 console - SendRaw TCU: 22 F1 24
10.01.2026 18:22:46,923 console - Raw Answer TCU: 62 F1 24 4A 37 41 33 2D 37 30 37 31 33 2D 41 41 41 00 00 00 00 00 00 00 00 00 00
10.01.2026 18:22:46,923 console - SendRaw TCU: 22 F1 08
10.01.2026 18:22:46,983 console - Raw Answer TCU: 7F 22 31
10.01.2026 18:22:46,992 console - SendRaw TCU: 22 F1 91
10.01.2026 18:22:47,073 console - Raw Answer TCU: 62 F1 91 4A 38 41 32 2D 37 30 37 31 39 2D 43 47 00 00 00 00 00 00 00 00 00 00 00

Но дальше пишет ошибку "Сборочный номер ECU не выпущен":

10.01.2026 18:22:47,122 console - errorLog(message: ##VR##sECUAssemblyNumber =
10.01.2026 18:22:47,122 console - errorLog(message: ##VR##sECUAssemblyNumberLineage length = 0
10.01.2026 18:22:47,122 com.avl.ditest.dicore.diflow.flow.kf_TCU_L663_2020_00_VXX_ECUAssemblyNumber_Non_Released25cgha

Так как паф не смог определить версию по ivs, он берёт последний известный номер версии из файла VIN.xml (находится вместе с vin.vbf в архиве asis.zip). При определённых действиях в пафе он загружает данный файл на сервер JLR, в котором пишет дату работы, версию пафа, а также основные версии всех модулей. Но если машину обновляли в гараже без интернета или кто-то не смог починить DSFM по нашей инструкции, то, соответственно, такой файл на сервер не отправится, и получится неконсистентность.

Краткое содержимое VIN.xml по части нашего модуля:

<module gmrdb_acronym="TCU">
<node_id>0x754</node_id>
<part_set>
<part did="0xF112" gmrdb_name="ECU_ASSEMBLY_PN">
<part_number type="WERS">LK72-70488-CH</part_number>

Прочитав этот файл, паф назначает версию как резервную (fallback) из VIN.xml:

10.01.2026 18:22:47,182 console - Got fallback assembly part number 'Optional[LK72-70488-CH]' from dsfm file for vin VIN / model L550 (DoIP) / domain TCU
10.01.2026 18:22:47,192 console - FallbackAssyPN: 'LK72-70488-CH'
10.01.2026 18:22:47,403 console - errorLog(message: ##---- sECUAssemblyNumberFallBack = LK72-70488-CH
10.01.2026 18:22:47,403 console - Setting assembly part number to: LK72-70488-CH for domain Telematic Control Unit Module [TCU] [3125]

Теперь посмотрим, почему паф не смог вычислить версию сам. Возьмём за основу резервную версию LK72-70488-CH и сравним её с данными, полученными напрямую из модуля TCU через UDS-команды — видим много несовпадений:

| DID | XML | Совпадение |
| ---- | ------------- | ---------- |
| F111 | J8A2-70719-CG | |
| F188 | J8A2-70712-AY | |
| F120 | J8A2-70712-BY | |
| F121 | J8A2-70712-CY | |
| F122 | J8A2-70712-FY | |
| F123 | J8A2-70712-GK | |
| F124 | J7A3-70713-AY | |
| F125 | J7A3-70713-SH | |

Теперь возьмём более новую версию (меняется последняя буква) LK72-70488-CJ — чуть лучше:

| DID | XML | Совпадение |
| ---- | ------------- | ---------- |
| F111 | J8A2-70719-CG | |
| F188 | J8A2-70712-AZ | |
| F120 | J8A2-70712-BZ | |
| F121 | J8A2-70712-CZ | |
| F122 | J8A2-70712-FY | |
| F123 | J8A2-70712-GK | |
| F124 | J7A3-70713-AZ | |
| F125 | J7A3-70713-SJ | ⚠ (±1) |

Ну и наконец берём самую последнюю, доступную в пафе, LK72-70488-CK для этого модуля:

| DID | XML | Совпадение |
| ---- | -------------- | ---------------- |
| F111 | J8A2-70719-CG | |
| F188 | J8A2-70712-AAA | |
| F120 | J8A2-70712-BAA | |
| F121 | J8A2-70712-CZ | |
| F122 | J8A2-70712-FY | |
| F123 | J8A2-70712-GK | |
| F124 | J7A3-70713-AAA | |
| F125 | J7A3-70713-SK | ⚠ (SH → SJ → SK) |

Как видим, совпадает всё, кроме одного компонента Calibration: в прошивке указано, что F125 должно быть J7A3-70713-SK, а по факту в модуле стоит J7A3-70713-SH (более старая версия). То есть до этого в модуле TCU обновили все компоненты, кроме одной калибровки. Из-за этого получилась неконсистентность по версиям, и паф не смог сам определить версию и в итоге выбрал последнюю известную из VIN.xml.

То, что мой скачанный конфиг AS-IS с сервера оказался по факту не самым актуальным, подтверждается ещё и модулем IPMA. В VIN.xml последняя дата AS-IS — 2023 год, для него была указана версия LK72-19H406-BE, а когда я подключил свой паф, он сам распознал более новую — LK72-19H406-BK — по UDS-ответам и своей логике.

Бонусом прикладываю скрипты в архиве:

1. uds_log_parser.py — парсит feedback.txt и делает CSV-файл, который можно импортировать в тот же Excel, чтобы удобно просматривать / фильтровать / сортировать версии ПО, калибровок и прочую информацию, полученную напрямую из модулей с течением времени.

2. compare_did.py — берёт на вход CSV (из uds_log_parser.py) и автоматически показывает, что изменилось по сравнению с данными, полученными в первый раз для каждого модуля.

3. allmodulesversions.py — берёт VIN.xml и делает 2 CSV: в одном показывает все модули и их основные версии ПО для всех конфигураций (AS_Ordered, As_Built, As_Is). Второй CSV показывает только те модули, в которых есть изменения. Если у вас есть несколько файлов VIN.xml, в которых отличается только конфигурация AS_IS, то их можно склеить и сделать один VIN.xml, в который вставить несколько полноценных блоков <module_record type="AS_IS">...</module_record>.

 

[K1R]

В процессе изучения того, что происходит, когда выполняется процедура select CCF или, например, изменение резины прямо в пафе, я обнаружил, что каждый раз:

1. Обновляется модуль SDLC (K8D2-14F642-CY в моем случае, причем в логе пишет что этот номер для GWM, а по факту он из SDLC) и соответствующие файлы Strategy, Secondary Bootloader, Calibration.

Спойлер

10.01.2026 18:32:27,646 console - Running flow Select_CCFg06pc1
10.01.2026 18:33:00,537 console - errorLog(message: ##---- enStateFlashFromAsBuilt ----##
10.01.2026 18:33:00,537 console - errorLog(message: enStateFlashFromAsBuilt.
10.01.2026 18:33:00,565 console - Wakeup flow: wk_GWM_GateWayModule_DoIPc7be7i
10.01.2026 18:33:01,596 console - Setting assembly part number to: K8D2-14F642-CY for domain Gateway Module 'A' [GWM] [3055]
10.01.2026 18:33:01,014 console - errorLog(message: ##! CHECKED K8D2-14F642-CY, InIvsForSelectedSeries = true
10.01.2026 18:33:01,693 console - Storing assembly fallback number: assypn K8D2-14F642-CY; vin VIN; domain Gateway Module 'A' [GWM] [3055]
10.01.2026 18:33:02,044 console - errorLog(message: found swpart C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\L8D2-14F530-JE.vbf, type Strategy
10.01.2026 18:33:02,044 console - errorLog(message: found swpart C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\L8D2-14F531-JD.vbf, type Calibration
10.01.2026 18:33:02,044 console - errorLog(message: Flashing CCF to address16302080 with length 4096
10.01.2026 18:33:35,126 console - errorLog(message: End of beginCCFFlash
10.01.2026 18:33:35,126 console - errorLog(message: Before flashSwPartsCCF
10.01.2026 18:33:35,126 console - errorLog(message: Files to be flashed:
10.01.2026 18:33:35,142 console - errorLog(message: C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\KPLA-14F532-BA.vbf
10.01.2026 18:33:35,142 console - errorLog(message: C:\Users\VXDIAG\AppData\Local\Temp\VIN.VBF
10.01.2026 18:33:35,337 console - errorLog(message: Downloading File: KPLA-14F532-BA.vbf
10.01.2026 18:33:35,469 console - errorLog(message: Transfer exit checksum (hex): 3E01
10.01.2026 18:33:35,469 console - errorLog(message: VBF flash segment checksum (dec): 15873
10.01.2026 18:33:35,473 console - errorLog(message: Checksums match: OK
10.01.2026 18:33:36,659 console - errorLog(message: Transfer exit checksum (hex): D0BE
10.01.2026 18:33:36,659 console - errorLog(message: VBF flash segment checksum (dec): 53438
10.01.2026 18:33:36,659 console - errorLog(message: Checksums match: OK
10.01.2026 18:33:36,789 console - errorLog(message: Transfer exit checksum (hex): 2322
10.01.2026 18:33:36,789 console - errorLog(message: VBF flash segment checksum (dec): 8994
10.01.2026 18:33:36,789 console - errorLog(message: Checksums match: OK
10.01.2026 18:33:40,312 console - errorLog(message: Downloading File: VIN.VBF
10.01.2026 18:33:40,496 console - errorLog(message: Transfer exit checksum (hex): CB98
10.01.2026 18:33:40,500 console - errorLog(message: VBF flash segment checksum (dec): 52120
10.01.2026 18:33:40,500 console - errorLog(message: Checksums match: OK
10.01.2026 18:33:40,504 console - errorLog(message: Flashed all files

2. Обновляется модуль BCM (LK72-14B476-AR в моем случае) и соответствующие файлы Strategy, Secondary Bootloader, Calibration, Signal Configuration.

Спойлер

10.01.2026 18:34:03,973 console - errorLog(message: ##! CHECKED LK72-14B476-AR, InIvsForSelectedSeries = true
10.01.2026 18:34:04,290 console - Setting assembly part number to: LK72-14B476-AR for domain Body Control Module [BCM] [3018]
10.01.2026 18:34:04,462 console - Storing assembly fallback number: assypn LK72-14B476-AR; vin VIN; domain Body Control Module [BCM] [3018]
10.01.2026 18:34:04,540 console - errorLog(message: found swpart C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\LPLA-14C184-AE.vbf, type Strategy
10.01.2026 18:34:04,540 console - errorLog(message: found swpart C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\LK72-14C185-AA.vbf, type Calibration
10.01.2026 18:34:04,540 console - errorLog(message: found swpart C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\LPLA-14C408-AA.vbf, type Signal Configuration
10.01.2026 18:34:04,550 console - errorLog(message: Flashing CCF to address16384000 with length 4096
10.01.2026 18:34:31,175 console - errorLog(message: End of PreFlash CCF
10.01.2026 18:34:31,190 console - errorLog(message: End of beginCCFFlash
10.01.2026 18:34:31,190 console - errorLog(message: Files to be flashed:
10.01.2026 18:34:31,190 console - errorLog(message: C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\JPLA-14C187-AA.vbf
10.01.2026 18:34:31,190 console - errorLog(message: C:\Users\VXDIAG\AppData\Local\Temp\VIN.VBF
10.01.2026 18:34:31,401 console - errorLog(message: Downloading File: JPLA-14C187-AA.vbf
10.01.2026 18:34:32,119 console - errorLog(message: Transfer exit checksum (hex): 1715
10.01.2026 18:34:32,119 console - errorLog(message: VBF flash segment checksum (dec): 5909
10.01.2026 18:34:32,119 console - errorLog(message: Checksums match: OK
10.01.2026 18:34:32,236 console - errorLog(message: Transfer exit checksum (hex): 110A
10.01.2026 18:34:32,236 console - errorLog(message: VBF flash segment checksum (dec): 4362
10.01.2026 18:34:32,236 console - errorLog(message: Checksums match: OK
10.01.2026 18:34:32,599 console - errorLog(message: Transfer exit checksum (hex): CF89
10.01.2026 18:34:32,599 console - errorLog(message: VBF flash segment checksum (dec): 53129
10.01.2026 18:34:32,599 console - errorLog(message: Checksums match: OK
10.01.2026 18:34:34,862 console - errorLog(message: Downloading File: VIN.VBF
10.01.2026 18:34:35,174 console - errorLog(message: Transfer exit checksum (hex): CB98
10.01.2026 18:34:35,178 console - errorLog(message: VBF flash segment checksum (dec): 52120
10.01.2026 18:34:35,178 console - errorLog(message: Checksums match: OK
10.01.2026 18:34:35,182 console - errorLog(message: Flashed all files
10.01.2026 18:36:52,944 console - Flow Select_CCFg06pc1 finished with status: Status OK: unknown code=0 null

Но обновление как бы не совсем обновление, скорее перезапись текущей версии, то есть для BCM, например, в пафе есть более свежая версия LK72-14B476-AT, но, судя по логу, записалась та же, что и была.

в jlr-ngs.ini есть такие строки
-Dcom.avl.ditest.ngs.mandatoryUpdateModuleNames=BCM,GWM,PCM
-Dcom.avl.ditest.ngs.showMandatoryModuleUpdates=false

Но если это так, тогда почему модуль PCM не обновлялся?

Кто уже обновлял модули в пафе — есть ли какая-либо последовательность, что за чем обновлять?
Нужно ли калибровки обновлять отдельно, или они автоматически обновляются при обновлении основной версии?

 

[smartgauges]

По неизвестной мне причине, предыдущее сообщение с перечислением файлов обрезалось.
Помимо jar файлов и jlr-ngs.ini в улучшениях так же добавлены/изменены:
4 vbf файла в C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\flash\
29 xml файлов в C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\IVS\
29 xml файлов в C:\Program Files (x86)\AVL_DiTEST\Pathfinder\data\Diagnosis\odxf\
Полный список файлов во вложении.

Сравнил все файлы (из C:\Program Files (x86)\AVL_DiTEST\Pathfinder\) по хэшам нашего пафа с китайским, теперь понятно что паф от зарубежных партнеров в который надо логиниться пользователем y-cai1 - это базовый паф 374 без улучшений.


Эта проблема возникает из-за того что vx manager хитро устанавливает свои драйвера, он просто переписывает оригинальную Бошевскую библиотеку "C:\Program Files (x86)\Bosch\VTX-VCI\VCI Software (JLR)\Products\JLR-DoIP\Dynamic Link Libraries\BVTX-VCI-PDU.dll". Поэтому если сначала установить vx manager, а потом паф(и бошевские драйвера вместе с ним) или просто обновить бошевские драйвера на рабочем пк, то файл библиотеки перепишется на оригинальный и все перестанет работать.

Что правда переписывает dll? Не добавляет в pdu_api_root.xml описание для своей dll, а использует бошевские пути?

 

[smartgauges]

Все эти дни я пытался понять, почему в процессе работы нашего пафа в логе feedback.log были сообщения "DSFMService - No assembly part number found for", а в китайском — нет, и насколько критичны такие ошибки. Самое интересное, что спустя несколько дней вышло наоборот: в нашем пафе не было таких ошибок, а в китайском для некоторых модулей они появились.

Если кратко, то сообщения "DSFMService - No assembly part number found for" не говорят напрямую о том, что софт блока имеет более новую версию,

Наверное проще логику понять по коду самого пафа, а не анализом логов?

 

[K1R]

Что правда переписывает dll? Не добавляет в pdu_api_root.xml описание для своей dll, а использует бошевские пути?

ага, pdu_api_root.xml остается неизменным в отличие от Diagnostic Associates например, при установке драйверов которых туда добавляется строчка.

Спойлер

<MVCI_PDU_API><SHORT_NAME>D_PDU_API_Bosch_JLR_DoIP</SHORT_NAME>
<DESCRIPTION>JLR - JLR-DoIP, D-PDU API by Bosch</DESCRIPTION>
<SUPPLIER_NAME>Bosch</SUPPLIER_NAME>
<LIBRARY_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/Dynamic Link Libraries/BVTX-VCI-PDU.dll"/>
<MODULE_DESCRIPTION_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/SupportFiles/MDF_Bosch_JLR-DoIP.xml"/>
<CABLE_DESCRIPTION_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/SupportFiles/CDF_Bosch_VCI.xml"/>
</MVCI_PDU_API>

еще в папке с измененной либой C:\Program Files (x86)\Bosch\VTX-VCI\VCI Software (JLR)\Products\JLR-DoIP\Dynamic Link Libraries\ я нашел два файла CDF.xml и MDF.xml которые тоже vx manager вставил, судя по тому что в CDF.xml указано <SUPPLIER_NAME>ALLSCANNER</SUPPLIER_NAME>, это как раз vxdiag.
А MDF.xml отличается от MDF_Bosch_JLR-DoIP.xml только несколькими строчками типа:
<IO_CTRL IDREF="PDU_IOCTL_MS_CLEAR_DOIP_ENTITY_LIST" />

так вот я добавил эти пути в pdu_api_root.xml, в настройках пафа выбрал этот интерфейс и заработало, ну по крайней мере базовые вещи работают. хз как это работает ведь в CDF.xml распиновка отличается от CDF_Bosch_VCI.xml.

это кстати отдельный топик, как подружить vcx se с topix cloud, из коробки он не работает, но судя по таким хакам может и можно.

я поставил на пробу весь софт для топикса, он снес паф, оставив только папку flash.

Наверное проще логику понять по коду самого пафа, а не анализом логов?


Посмотреть вложение 9204

проще когда задача точечная, но в моем случае я скорее хотел изучить все процессы в более широком смысле
а ты кстати не видел есть ли версионность у файлов as-is которые хранятся на серверах jrl, т.е. чтобы качать as-is но при этом указывая версию 1,2,3...?

 

[peekay]

Hello folks,
Im trying to "downgrade" IPMA firmware on my L551 to version M8D2-19H406-AB, and I cannot understand a few things. The L550, L551 and X540 used the same physical part (L8B2-14F395-CB). They also use the same strategy files (M8D2-14F397-AB+M8D2-14F397-BB). The only difference is the calibration file (L551 M8D2-14F398-AB, L550 MK72-14F398-AB, X540 M9C3-14F398-AB).
Now when loading the first calibration file M8D2-14F397-BB, the procedure should be the same for all 3 vehicles, and it should return the same hash.
The module returns a matching hash for the L550, but the part was taken from a Defender.

But, in the following xml files (M8D2-19H406-AB.xml, MK72-19H406-AB.xml, M9C3-19H406-AB.xml found in odxf.zip) the same strategy file M8D2-14F397-AB has 3 different hashes in each xml file. The -AB strategy file has 3 blocks, but each .xml file should have the same hash for the same block.
This is also true of M8D2-14F397-BB.

All following firmware versions, -AC, -AF, etc. have the same hash for a strategy file. Only the first one has 3 different hash values.
My understanding is that the vehicle is determined by PAF when it loads the "Signature" for a given file, that is specific for the vehicle.

Anyone have any ideas, how to how the hash for the same file can be different for the same hardware part number?
Thanks

 

[peekay]

Following up my previous post with a real example. In the firmware flashing process, each .vbf file is sent in one or more blocks. At the end of transfer of a block, the module sends a hash back to PAF.
If you look at the files, L550/MK72-19H406-AF.xml L551/M8D2-19H406-AF.xml and X540/M9C3-19H406-AF.xml, they all contain the same has for M8D2-14F397-BF Block 1:
<SD SI="HashValue">460163CC499336434B4616355789355E1BA50E4D87DB8CBCC96750E4887290A7</SD>
Since the data over which the hash is calculated is exactly the same. The hash is dependent on the block of data in the file and not the vehicle.

But if you look at the files
L550/MK72-19H406-AB.xml:
<SD SI="HashValue">E19CF3852EEBBC5910FFB221422A9A33F567F3D33BD4B9E914C8E1D02317A9D2</SD>

L551/M8D2-19H406-AB.xml:
<SD SI="HashValue">20CC0829B4B19F5F5846A446572BB21A2735244270B837F16AD6FB4E29EC02B6</SD

X540/M9C3-19H406-AB.xml:
<SD SI="HashValue">DDD7D09FD1AE8EC373210B63150B7848025214E53F97F092AB8936F06121CE16</SD>

These are hash values for file M8D2-14F397-BB Block 1. How can a module generate different hashes for the same block of data?
In my case, when this block is loaded, the module returns the hash that matches L550 (Disco Sport). The module is from a Defender.

Thanks

 

[smartgauges]

ага, pdu_api_root.xml остается неизменным в отличие от Diagnostic Associates например, при установке драйверов которых туда добавляется строчка.

Спойлер

<MVCI_PDU_API><SHORT_NAME>D_PDU_API_Bosch_JLR_DoIP</SHORT_NAME>
<DESCRIPTION>JLR - JLR-DoIP, D-PDU API by Bosch</DESCRIPTION>
<SUPPLIER_NAME>Bosch</SUPPLIER_NAME>
<LIBRARY_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/Dynamic Link Libraries/BVTX-VCI-PDU.dll"/>
<MODULE_DESCRIPTION_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/SupportFiles/MDF_Bosch_JLR-DoIP.xml"/>
<CABLE_DESCRIPTION_FILE URI="file:///C:/Program Files (x86)/Bosch/VTX-VCI/VCI Software (JLR)/Products/JLR-DoIP/SupportFiles/CDF_Bosch_VCI.xml"/>
</MVCI_PDU_API>

еще в папке с измененной либой C:\Program Files (x86)\Bosch\VTX-VCI\VCI Software (JLR)\Products\JLR-DoIP\Dynamic Link Libraries\ я нашел два файла CDF.xml и MDF.xml которые тоже vx manager вставил, судя по тому что в CDF.xml указано <SUPPLIER_NAME>ALLSCANNER</SUPPLIER_NAME>, это как раз vxdiag.
А MDF.xml отличается от MDF_Bosch_JLR-DoIP.xml только несколькими строчками типа:
<IO_CTRL IDREF="PDU_IOCTL_MS_CLEAR_DOIP_ENTITY_LIST" />

так вот я добавил эти пути в pdu_api_root.xml, в настройках пафа выбрал этот интерфейс и заработало, ну по крайней мере базовые вещи работают. хз как это работает ведь в CDF.xml распиновка отличается от CDF_Bosch_VCI.xml.

это кстати отдельный топик, как подружить vcx se с topix cloud, из коробки он не работает, но судя по таким хакам может и можно.

я поставил на пробу весь софт для топикса, он снес паф, оставив только папку flash.


проще когда задача точечная, но в моем случае я скорее хотел изучить все процессы в более широком смысле
а ты кстати не видел есть ли версионность у файлов as-is которые хранятся на серверах jrl, т.е. чтобы качать as-is но при этом указывая версию 1,2,3...?

приложения похоже совсем не читают CDF.xml/MDF.xml файлы, а запрашивают напрямую нужную инфу через апи, в пафе я не видел обращения к xml файлам
если клауд может работать с любым dpdu адаптером, то и клауд должен работать с vcx, нужен только корректный pdu_api_root.xml
если клауд залочен на оригинальный жлр бош, то тогда использовать его китайский клон - vnci
версионности не видел в asis файлах, что за идиот придумал автоматическую загрузку/выгрузку asis файлов? это же любой может ccf подправить(испортить) для любого авто

 

[agnostiks]

сервера DSFM сейчас работают?

 

[K1R]

Following up my previous post with a real example. In the firmware flashing process, each .vbf file is sent in one or more blocks. At the end of transfer of a block, the module sends a hash back to PAF.
If you look at the files, L550/MK72-19H406-AF.xml L551/M8D2-19H406-AF.xml and X540/M9C3-19H406-AF.xml, they all contain the same has for M8D2-14F397-BF Block 1:
<SD SI="HashValue">460163CC499336434B4616355789355E1BA50E4D87DB8CBCC96750E4887290A7</SD>
Since the data over which the hash is calculated is exactly the same. The hash is dependent on the block of data in the file and not the vehicle.

But if you look at the files
L550/MK72-19H406-AB.xml:
<SD SI="HashValue">E19CF3852EEBBC5910FFB221422A9A33F567F3D33BD4B9E914C8E1D02317A9D2</SD>

L551/M8D2-19H406-AB.xml:
<SD SI="HashValue">20CC0829B4B19F5F5846A446572BB21A2735244270B837F16AD6FB4E29EC02B6</SD

X540/M9C3-19H406-AB.xml:
<SD SI="HashValue">DDD7D09FD1AE8EC373210B63150B7848025214E53F97F092AB8936F06121CE16</SD>

These are hash values for file M8D2-14F397-BB Block 1. How can a module generate different hashes for the same block of data?
In my case, when this block is loaded, the module returns the hash that matches L550 (Disco Sport). The module is from a Defender.

Thanks

So you took a module from a Defender and put it into your L551, and it is recognized as if it came from an L550? Where do you see the hashes calculated by the ECU — in feedback.txt?
Why do you need to downgrade the IPMA firmware?

There is only one thing that is clear: if the file is the same but the specified hashes are different, then it means that the hash function calculates not only the file itself, but also adds other data to the hash function — something like HASH(block data + vehicle-specific context).

приложения похоже совсем не читают CDF.xml/MDF.xml файлы, а запрашивают напрямую нужную инфу через апи, в пафе я не видел обращения к xml файлам
если клауд может работать с любым dpdu адаптером, то и клауд должен работать с vcx, нужен только корректный pdu_api_root.xml
если клауд залочен на оригинальный жлр бош, то тогда использовать его китайский клон - vnci
версионности не видел в asis файлах, что за идиот придумал автоматическую загрузку/выгрузку asis файлов? это же любой может ccf подправить(испортить) для любого авто

Я так понимаю для топикса нужно чтобы адаптер был распознан и показывался в vci manager, судя по скринам в инетах, vnci тоже видимо как то прикидывается бошем и его видно в vci manger, вот это надо раскурить)

сервера DSFM сейчас работают?

да

 

[billt928]

Никто не подскажет, что в CCF (VBF) менять на Range Rover Sport 2 L494 2022 для дооснащение Адаптивным Круиз Контролем? Нашел много вариантов, но какой правильный пока не понятно. Буду признателен.

Hopefully this helps. I just did ACC with lane center assist on my 2022 L494 SVR. You can sort out the tow assist settings and ignore those
I also provided the the software version I had to flash my IPMA to for lane center. That vin in the picture you should be able to get the IVS file

 

[billt928]

Can anyone tell me what CCF (VBF) changes I need to make on my 2022 Range Rover Sport 2 L494 to retrofit Adaptive Cruise Control? I've found a lot of options, but I'm still not sure which one is right. I'd appreciate

 

[peekay]

So you took a module from a Defender and put it into your L551, and it is recognized as if it came from an L550? Where do you see the hashes calculated by the ECU - in feedback.txt?
Why do you need to downgrade the IPMA firmware?

There is only one thing that is clear: if the file is the same but the specified hashes are different, then it means that the hash function calculates not only the file itself, but also adds other data to the hash function — something like HASH(block data + vehicle-specific context) .

The "base IPMA hardware" for the newer vehicle architectures is the same, the only difference being the firmware that is loaded onto it. I have a spare IPMA that was originally on the Defender,and I can flash pretty any firmware for Velar, Evoque, Disco Sport, etc. The very first firmware version of the Evoque and the EPace (common strategy with Disco Sport), can't be flashed failing at signature verification. For each block the ECU send back a signature that is seen in the DoIP packets and feedback.txt.

All other versions of the Evoque firmware can be loaded onto the same hardware too. So I cannot understand why the vehicle specific context only applies to the "first version" of firmware. The only idea I had was maybe, a "blanked/virgin" piece of hardware is needed for flashing the first version, but then again the Disco sport first version is allowed. I would expect only the Defender first version to be allowed.

I'm trying to see if older firmware versions for my vehicle support "ACC with lane centering" (similar to what @billt928 has done). It appears that some folks of other models have been able to retrofit it with older versions of firmware (+ CCF edits). Just CCF edit, did not work in my vehicle.

 

[billt928]

I have some similar on a 2019 Velar without 360 cameras. And was able to add lane center assist to the existing ACC by flashing the IMPA to a different version and a single line edit to the CCF file

 

[K1R]

The "base IPMA hardware" for the newer vehicle architectures is the same, the only difference being the firmware that is loaded onto it. I have a spare IPMA that was originally on the Defender,and I can flash pretty any firmware for Velar, Evoque, Disco Sport, etc. The very first firmware version of the Evoque and the EPace (common strategy with Disco Sport), can't be flashed failing at signature verification. For each block the ECU send back a signature that is seen in the DoIP packets and feedback.txt.

All other versions of the Evoque firmware can be loaded onto the same hardware too. So I cannot understand why the vehicle specific context only applies to the "first version" of firmware. The only idea I had was maybe, a "blanked/virgin" piece of hardware is needed for flashing the first version, but then again the Disco sport first version is allowed. I would expect only the Defender first version to be allowed.

I'm trying to see if older firmware versions for my vehicle support "ACC with lane centering" (similar to what @billt928 has done). It appears that some folks of other models have been able to retrofit it with older versions of firmware (+ CCF edits). Just CCF edit, did not work in my vehicle.

Ok, I see now what you’re trying to achieve. Have you checked the first firmware version for other modules (ABS, AWD, IMPB, etc.) to see whether they also have different hashes for the same block of data?

What if you take a newer firmware XML file and edit it to reference the older VBF files, since all the hashes are the same in the newer firmwares? In other words, you would be flashing the older firmware while Pathfinder and the vehicle treat it as a newer version.

 

[safari200009]

Здраствуйте. Первый раз на етом форуме. Купил Jaguar F-Pace 2018 год из Америки.
1) Не могу скачать (пишет что не заслужил)
2) у меня есть JLR Pathfinder не могу залоговатся а когда вставляю -Dcom.avl.ditest.ngs.skiplogin=true
выкидывает с програмыю
3) Где взять редактор CCF
Помогите пожалуста.

 

[peekay]

Ok, I see now what you're trying to achieve. Have you checked the first firmware version for other modules (ABS, AWD, IMPB, etc.) to see whether they also have different hashes for the same block of data?

What if you take a newer firmware XML file and edit it to reference the older VBF files, since all the hashes are the same in the newer firmwares? In other words, you would be flashing the older firmware while Pathfinder and the vehicle treat it as a newer version.

Looking at the hashes across L550/L551 modules, some are the same, some are different. This even though the hardware part number is the same.

The contents of the XML dont matter directly, since Im using my own software to MITM data into the stream. For each block from a vbf file, the module sends back a hash (whose expected value is in the xml file). Then on completion of all blocks of a vbf file, the PAF side is expected to send a Signature, which the module will verify. I cant use a signature for a .vbf file from a .xml file, where that specific .vbf file is not used. So the signature from a newer versio .xml file cannot be used when data from an older version .vbf is sent to the module. The module rejects the signature, and programming terminates.

One more possibility that I can think of is that Pathfinder, has a different programming sequence for the first version. Since Im just repeating the programming sequence of subsequent versions, it doest work for the initialversion.
I have tried the "superuser" mode where the list of firmware versions is shown and a version can be selected to be flashed. But for whatever reason, PAF always attempts to flash the latest version, ignoring my choice. If I can understand why PAF ignores my choice,then perhaps we can figure out if the programming sequence for the initial version is different.

 

[K1R]

Looking at the hashes across L550/L551 modules, some are the same, some are different. This even though the hardware part number is the same.

The contents of the XML dont matter directly, since Im using my own software to MITM data into the stream. For each block from a vbf file, the module sends back a hash (whose expected value is in the xml file). Then on completion of all blocks of a vbf file, the PAF side is expected to send a Signature, which the module will verify. I cant use a signature for a .vbf file from a .xml file, where that specific .vbf file is not used. So the signature from a newer versio .xml file cannot be used when data from an older version .vbf is sent to the module. The module rejects the signature, and programming terminates.

One more possibility that I can think of is that Pathfinder, has a different programming sequence for the first version. Since Im just repeating the programming sequence of subsequent versions, it doest work for the initialversion.
I have tried the "superuser" mode where the list of firmware versions is shown and a version can be selected to be flashed. But for whatever reason, PAF always attempts to flash the latest version, ignoring my choice. If I can understand why PAF ignores my choice,then perhaps we can figure out if the programming sequence for the initial version is different.

Interesting, on which level you are doing MiTM - network or DLL?

While I was reading about the most expensive ccf editor (sx-tool) which @billt928 is using, I've found on their website note "With JET Master – the SX-Tool you can virginize the used BCM module VIN via Enet". So, maybe you need to virginize your IPMA module first, erase the VIN at least or something like that.

How to access "superuser" mode in PAF?

 

[billt928]

No. You can just re-flash it using SX-Tool. I used a vin from a can with the features so I could look at the as-built IVS file and see what version was loaded. Selected it and flashed it to my existing IPMA module That way it retained my original VIN number. There is a few ways to go about. Just load it in sx-tool and or edit the As-built IVS file and add the correct information for the module.

After I flashed the IPMA module to the version I needed. I also selected an older version of the file I then edited the as built IVS while I had pathfinder open and did a update module and it wrote all the firmware, calibration and strategy files and then went through the leaning of CCF for all modules that required it. And I also went in and modified customer features and when it saved the changes to the CCF. It also updated the files checksum and that seems make that telematics code for the CCF as-built mismatch

Feel fee to pm me with any questions.

 

[peekay]

Interesting, at which level you are doing MiTM - network or DLL?

While I was reading about the most expensive ccf editor (sx-tool) which @billt928 is using, I've found on their website note "With JET Master – the SX-Tool you can virginize the used BCM module VIN via Enet". So, maybe you need to virginize your IPMA module first, erase the VIN at least or something like that.

How to access "superuser" mode in PAF?

TCP proxy.

I finally managed to convince Pathfinder to upload the first version of firmware. The sequence is no different and it fails the hash check of the first block. So there's definitely something going on here.

ive talked to Gary from Autosvs. Not sure if modules other than BCM can be vurginized. Don't think they would've researched something that is not a frequent request.