# CDD (CANdela Diagnostic Description) > A CDD (CANdela Diagnostic Description) is the XML file produced by Vector CANdelaStudio that describes the diagnostic interface of one ECU: sessions, UDS services and sub-functions, data identifiers, routines, trouble codes and the SecurityAccess levels that guard them. It is a vendor format, not an ISO standard, but it is as common in the supply chain as ODX. On the bench it turns raw identifiers into names and tells a tester which routines exist and what they expect. A CDD file is the Vector CANdela description of an ECU diagnostic interface: sessions, services, DIDs, routines and security levels. What it holds and how testers use it. Source: https://auto-st.com/glossary/cdd ยท Updated: 2026-10-07 ## 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. ## FAQ **Is a CDD the same as ODX?** No. ODX is the ISO 22901-1 exchange format; CDD is the native format of Vector CANdelaStudio. Both describe the same things, and CANdelaStudio can export a CDD as ODX or as a PDX package, so most teams end up with both. **Can a security tester work without the CDD?** Yes, enumeration finds sessions, services and DIDs without any file. The CDD adds names, the expected session and security level per service, and the list of routines with their payloads, which makes the results readable and the routine scan safe. **Does the CDD leave the test bench?** In AutoST it is attached to the ECU on your instance, hosted in the EU or on your own servers, and is not shared further. Many suppliers treat the file as confidential, and the test setup has to respect that. ## Sources - [Vector Informatik: CANdelaStudio product documentation](https://www.vector.com/int/en/products/products-a-z/software/candelastudio/) - [ISO 22901-1:2008 Road vehicles, Open diagnostic data exchange (ODX), Part 1: Data model specification](https://www.iso.org/standard/41207.html) - [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer](https://www.iso.org/standard/72439.html) ## Related - [ODX (Open Diagnostic Data Exchange)](https://auto-st.com/glossary/odx) - [PDX (Packaged ODX)](https://auto-st.com/glossary/pdx) - [DID (Data Identifier)](https://auto-st.com/glossary/did) - [RID (Routine Identifier)](https://auto-st.com/glossary/rid) - [Your ODX and CDD, turned into tests.](https://auto-st.com/did-routine-scanning) - [ODX-driven testing: turn your diagnostic data into tests](https://auto-st.com/insights/odx-driven-testing) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/cdd