CDD (CANdela Diagnostic Description)

What is CDD?

A CDD file (CANdela Diagnostic Description) is Vector’s XML-based description of everything an ECU offers on its diagnostic interface: the sessions, the UDS services and their sub-functions, the data identifiers (DIDs) with data types and scalings, the routines (RIDs), the diagnostic trouble codes and the SecurityAccess levels that protect them. It is authored in CANdelaStudio and is the file a Tier-1 hands to the OEM so that the development tester, the end-of-line tester and the workshop tester all talk to the ECU the same way.

Unlike ODX, CDD is not an ISO standard but a vendor format. In the German-speaking supply chain it is at least as common as ODX, because many suppliers author in CANdelaStudio and export ODX or PDX only when a customer asks for it.

Where is it defined?

The format is defined by Vector Informatik in the CANdelaStudio documentation; there is no public specification outside the tool. What it describes is UDS per ISO 14229-1: the service identifiers, sub-functions, DIDs, RIDs and negative response codes in a CDD are the ones the standard defines, plus the manufacturer-specific ranges the ECU uses. The standardised equivalent is ODX, defined in ISO 22901-1, and CANdelaStudio can export a CDD into ODX 2.2 or into a PDX package.

What it means in practice

On the bench a CDD is the ECU’s map. Enumeration without it gives you numbers: DID 0xF190 answers in default session, RID 0x0203 exists in extended session. With the CDD those lines become “VIN” and “Check programming preconditions”, and a finding reads like your diagnostic spec instead of a hex dump.

The second use is scoping. The CDD states which session and which security level a service should need. Where the ECU answers in a lower session than the file says, or without SecurityAccess, you have a discrepancy worth a finding. We regularly see identification DIDs (serial number, fingerprints) marked as protected in the CDD and writable on the real ECU, and routines the file ties to the programming session answering in extended session.

The third use is routines. Routine identifiers cannot be brute-forced sensibly: the payload matters, the result depends on preconditions and some routines are destructive. A CDD tells you which routines exist and what they expect, so you call exactly those and nothing else.

How AutoST tests it

AutoST imports CDD files alongside ODX, ODX-D and PDX, normalises them into DIDs and routines and attaches them to the ECU once; every later scan uses them. Discovered DIDs show their CDD name, routines (0x31) are started only when the file defines them, with a payload you can override, and the optional write probing (0x2E) compares the protection the file promises with what the ECU does. Confidential files stay on your instance.

Common misunderstandings

A CDD describes what the ECU is meant to do, not what it does. Treat it as a hypothesis to test, not as a result. It is also not a test specification: beyond the session and security-level mapping it says nothing about expected security behaviour, so the attack-side checks (seed quality, lockout, undocumented services) still have to come from the tester.