DID (Data Identifier)

Was ist eine DID?

Ein Data Identifier ist eine 16-Bit-Zahl, die für einen Datensatz im Steuergerät steht. Statt Speicher zu adressieren, fragt der Tester nach einer DID, und das Steuergerät liefert den Datensatz in der Länge und Kodierung, die der Hersteller festgelegt hat. 22 F1 90 liest die VIN, und das Steuergerät antwortet 62 F1 90 gefolgt von 17 Bytes; 22 F1 86 liefert die aktive Diagnose-Session als ein Byte, 62 F1 86 03 für die Extended Session.

Mehrere Services arbeiten mit DIDs: ReadDataByIdentifier (0x22) und WriteDataByIdentifier (0x2E), ReadScalingDataByIdentifier (0x24), ReadDataByPeriodicIdentifier (0x2A, das nur das untere Byte des Bereichs F2xx nutzt), DynamicallyDefineDataIdentifier (0x2C) und InputOutputControlByIdentifier (0x2F).

Wo ist es definiert?

ISO 14229-1:2020 Anhang C listet die Standard-Data-Identifier. Der Identifikationsblock 0xF180 bis 0xF19F enthält Boot- und Anwendungssoftware-Identifikation (F180 bis F182), die Fingerprints (F183 bis F185), die aktive Session (F186), Ersatzteil- und Softwarenummern (F187 bis F189), die Lieferanten-Identifier (F18A, F18B), die Seriennummer (F18C), die VIN (F190), die Hardwarenummer (F191), das Programmierdatum (F199) und die Werkstattcodes (F198, F19A). Weitere Bereiche sind reserviert für periodische Identifier (F200 bis F2FF), dynamisch definierte Identifier (F300 bis F3FF), OBD (F400 bis F8FF), Tachograph, Airbag und Safety-Systeme sowie lieferantenspezifische Nutzung (FD00 bis FEFF). Die Bereiche 0x0100 bis 0xA5FF und weitere sind herstellerspezifisch und stehen in der ODX- oder CDD-Datei des Steuergeräts.

Was es in der Praxis bedeutet

DIDs sind der Ort, an dem Informationen abfließen und unerlaubte Änderungen passieren. Am Prüfstand liest ein Tester zuerst den Identifikationsblock, weil er Softwarestand, Hardwarerevision und Programmierhistorie verrät und fast jedes Steuergerät ihn beantwortet. Als Zweites folgt ein Sweep über den ganzen Identifier-Raum pro Session, weil die interessanten DIDs die undokumentierten sind: Debug-Zähler, interne Zustände, manchmal Schlüsselmaterial oder Konfigurationsbytes.

Wir sehen regelmäßig Identifikations-DIDs, die in der Extended Session ohne SecurityAccess schreibbar sind, womit jeder die Fingerprints oder die Seriennummer überschreiben kann und die Nachvollziehbarkeit, wer das Steuergerät programmiert hat, verloren geht. Wir sehen auch DIDs, die beim Schreiben jede Länge akzeptieren, und Steuergeräte, die für dieselbe DID in verschiedenen Sessions unterschiedliche Daten liefern.

Wie AutoST es testet

AutoST liest standardmäßig den Identifikationsbereich 0xF180 bis 0xF19F und kann den vollen Raum 0x0000 bis 0xFFFF in jeder gefundenen Session durchlaufen, über CAN oder DoIP. Eine importierte ODX-, PDX- oder CDD-Datei benennt die gefundenen Identifier und liefert die erwarteten Längen, und die optionale Schreibtest-Phase prüft, welche DIDs ein 0x2E-Schreiben annehmen, mit Falsche-Länge- und Rücklese-Checks, standardmäßig aus und vor dem Start bestätigt.

Häufige Missverständnisse

Eine DID ist keine Speicheradresse; ReadMemoryByAddress (0x23) ist ein anderer Service mit anderem Risikoprofil. Und eine DID, die in der Default Session 0x31 antwortet, antwortet in der Extended Session vielleicht trotzdem, ein Sweep in einer Session sagt also nichts über die anderen aus.