CDD (CANdela Diagnostic Description)

Was ist CDD?

Eine CDD-Datei (CANdela Diagnostic Description) ist Vectors XML-basierte Beschreibung von allem, was ein Steuergerät an seiner Diagnoseschnittstelle anbietet: die Sessions, die UDS-Services mit ihren Sub-Funktionen, die Data Identifier (DIDs) mit Datentypen und Skalierungen, die Routinen (RIDs), die Fehlercodes und die SecurityAccess-Level, die sie schützen. Erstellt wird sie in CANdelaStudio, und sie ist die Datei, die ein Tier-1 dem OEM übergibt, damit Entwicklungstester, Bandende-Tester und Werkstatttester alle gleich mit dem Steuergerät sprechen.

Anders als ODX ist CDD kein ISO-Standard, sondern ein Herstellerformat. In der deutschsprachigen Lieferkette ist es mindestens so verbreitet wie ODX, weil viele Zulieferer in CANdelaStudio arbeiten und ODX oder PDX nur exportieren, wenn ein Kunde danach fragt.

Wo ist es definiert?

Das Format definiert Vector Informatik in der CANdelaStudio-Dokumentation; eine öffentliche Spezifikation außerhalb des Tools gibt es nicht. Was es beschreibt, ist UDS nach ISO 14229-1: Die Service Identifier, Sub-Funktionen, DIDs, RIDs und Negative Response Codes in einer CDD sind die aus dem Standard, plus die herstellerspezifischen Bereiche, die das Steuergerät nutzt. Das standardisierte Gegenstück ist ODX nach ISO 22901-1, und CANdelaStudio exportiert eine CDD nach ODX 2.2 oder in ein PDX-Paket.

Was es in der Praxis bedeutet

Am Prüfstand ist die CDD die Landkarte des Steuergeräts. Enumeration ohne Datei liefert Zahlen: DID 0xF190 antwortet in der Default Session, RID 0x0203 existiert in der Extended Session. Mit der CDD werden daraus “VIN” und “Programmiervoraussetzungen prüfen”, und ein Finding liest sich wie deine Diagnosespezifikation statt wie ein Hex-Dump.

Der zweite Nutzen ist Abgrenzung. Die CDD sagt, welche Session und welches Security Level ein Service brauchen soll. Wo das Steuergerät in einer niedrigeren Session antwortet als die Datei angibt, oder ohne SecurityAccess, hast du eine Abweichung, die ein Finding wert ist. Wir sehen regelmäßig Identifikations-DIDs (Seriennummer, Fingerprints), die in der CDD als geschützt markiert und am echten Steuergerät beschreibbar sind, und Routinen, die die Datei an die Programming Session bindet und die in der Extended Session antworten.

Der dritte Nutzen sind Routinen. Routine Identifier lassen sich nicht sinnvoll per Brute Force durchprobieren: Der Payload zählt, das Ergebnis hängt von Vorbedingungen ab und manche Routinen sind destruktiv. Die CDD sagt dir, welche Routinen existieren und was sie erwarten, also rufst du genau diese auf und keine anderen.

Wie AutoST es testet

AutoST importiert CDD-Dateien neben ODX, ODX-D und PDX, normalisiert sie zu DIDs und Routinen und hängt sie einmal ans Steuergerät; jeder spätere Scan nutzt sie. Gefundene DIDs zeigen ihren CDD-Namen, Routinen (0x31) werden nur gestartet, wenn die Datei sie definiert, mit einem Payload, den du überschreiben kannst, und die optionalen Schreibtests (0x2E) vergleichen den Schutz, den die Datei verspricht, mit dem, was das Steuergerät tut. Vertrauliche Dateien bleiben auf deiner Instanz.

Häufige Missverständnisse

Eine CDD beschreibt, was das Steuergerät tun soll, nicht, was es tut. Behandle sie als Hypothese, die du testest, nicht als Ergebnis. Eine Testspezifikation ist sie auch nicht: Außer der Zuordnung von Session und Security Level sagt sie nichts über erwartetes Sicherheitsverhalten, also müssen die Prüfungen aus Angreifersicht (Seed-Qualität, Lockout, undokumentierte Services) weiterhin vom Tester kommen.