PDX (Packaged ODX)

Was ist PDX?

PDX (Packaged ODX) ist das Containerformat, in dem ODX-Diagnosedaten ausgetauscht werden. Es ist ein ZIP-Archiv mit fester Struktur: ein index.xml-Katalog, der jede Datei im Paket auflistet, und die ODX-Dateien selbst, jede mit einer Endung, die ihre Kategorie benennt. Die Diagnoseschicht-Dateien (.odx-d) beschreiben Sessions, Services, Data Identifier, Routinen und Security Level des Steuergeräts; die Kommunikationsparameter (.odx-c, .odx-cs) beschreiben Adressierung und Timing auf CAN oder DoIP; .odx-f trägt Flashdaten, .odx-v Fahrzeuginformationen, .odx-e die ECU-Konfiguration und .odx-fd das Funktionsverzeichnis. Java-Jobs für komplexe Abläufe reisen als .jar im selben Paket mit.

Der Sinn von PDX: Eine vollständige Diagnosebeschreibung für ein Steuergerät oder ein ganzes Fahrzeug kommt als eine Datei mit prüfbarem Inhaltsverzeichnis an, nicht als Ordner loser XML-Dateien, die zueinander passen können oder auch nicht.

Wo ist es definiert?

PDX ist zusammen mit ODX in ISO 22901-1 definiert, der ISO-Veröffentlichung des ASAM-Standards MCD-2 D. ODX 2.2.0 ist die Version, die die meisten Tools heute austauschen. Was die Daten beschreiben, ist UDS nach ISO 14229-1: Die Service Identifier, Sub-Funktionen, DIDs und RIDs einer ODX-D-Schicht entsprechen eins zu eins den Requests, die ein Tester sendet.

Was es in der Praxis bedeutet

Für einen Security-Tester ist eine PDX der nützlichste Input, den ein OEM liefern kann, weil sie die Fragen beantwortet, die die Enumeration sonst raten muss: welche Sessions existieren und wie man hineinkommt, welches Security Level jeder Service braucht, welche DIDs Identifikationsdaten und welche Kalibrierung sind, und welche Routinen es mit welchen Payloads gibt. Eine DID-Liste aus der PDX macht aus “0xF18C antwortet in der Default Session” den Satz “die Seriennummer des Steuergeräts ist in der Default Session lesbar”, was korrekt ist, und aus “0xF18C ist ohne SecurityAccess beschreibbar” ein Finding.

Zwei Dinge stolpern Leute regelmäßig. Eine PDX beschreibt oft eine Variantenfamilie, mehrere ECU-Varianten in einem Paket, die sich in den unterstützten DIDs unterscheiden; der Tester muss die Variante wählen, die zum Muster am Prüfstand passt. Und PDX-Pakete werden häufig aus einer CDD oder einer OEM-Autorendatenbank generiert, Abweichungen zwischen Paket und echtem Steuergerät sind also normal und selbst dokumentationswürdig: Ein Service, der laut Datei SecurityAccess braucht und den das Steuergerät ohne gewährt, gehört genau so in den Verifikationsbericht.

Wie AutoST es testet

AutoST importiert PDX-Pakete ebenso wie ODX, ODX-D und Vector-CDD-Dateien, zieht die Diagnoseschichten aus dem Paket und normalisiert sie zu DIDs und Routinen am Steuergerät. Die Namen reichern die Enumerationsergebnisse an, Routinen (0x31) werden nur aufgerufen, wenn das Paket sie definiert, und die optionalen Schreibtests (0x2E) prüfen, ob DIDs, die die Datei als geschützt markiert, tatsächlich geschützt sind. Das Paket bleibt auf deiner Instanz und wird von jedem späteren Scan wiederverwendet.

Häufige Missverständnisse

Eine PDX ist keine Flashdatei, auch wenn sie eine enthalten kann, und keine Testspezifikation. Es ist die Aussage des Herstellers, was das Steuergerät anbieten soll. Ein Security-Test vergleicht diese Aussage mit dem, was das Steuergerät tatsächlich tut; die Unterschiede sind das Ergebnis.