ODX and CDD diagnostic definitions
ODX and CDD diagnostic definitions: ODX is the XML-based diagnostic-data exchange format standardized as ASAM MCD-2 D and in the ISO 22901-1 family. The page also includes a worked example and measurement sequence.
Technical frame
ODX and CDD diagnostic definitions: ODX is the XML-based diagnostic-data exchange format standardized as ASAM MCD-2 D and in the ISO 22901-1 family. The page also includes a worked example and measurement sequence.
The technical values here expose the standard, protocol or physical relationship directly; model-specific service values are linked through the matching model/variant dossier.
The goal is not only to define the term but to let the reader calculate and interpret what the data means in a scan, scope or physical test.
Concrete technical facts
- ODX is the XML-based diagnostic-data exchange format standardized as ASAM MCD-2 D and in the ISO 22901-1 family.
- ODX can describe diagnostic services, request/response parameters, data-object properties (DOPs), sessions and ECU-variant relationships in machine-readable form.
- A DOP can centralize bit/byte coding, physical type, unit and computation/decoding information.
- Package parts such as diagnostic and vehicle information depend on the ODX release and project structure.
- CDD is Vector CANdelaStudio diagnostic-description format; it is not identical to ODX and conversions require semantic validation.
- A mismatched diagnostic-description release can interpret DIDs/routines incorrectly even when ECU communication works, so ECU software/variant identity must match.
Worked example
- Decode example: a 2-byte UWORD raw value of 1250 with factor 0.1 becomes 125.0 physical units; byte order and offset come from the DOP definition.
Data-structure example
raw: 0x04E2 = 1250
factor: 0.1
physical: 125.0Measurement and verification sequence
- Match ECU variant/software ID to the diagnostic-description release.
- Capture raw request/response bytes independently of the description.
- Verify DID/routine parameter DOP coding/endianness/factor.
- Cross-check decoded results against an independent OEM/scan value.
Fault-separation logic
- Is a valid command present and are power/ground/network healthy?
- Does feedback follow the command?
- Does an independent physical measurement confirm the output?
- Is the fault limited to a specific temperature/load/speed condition?
- Does the result remain stable when the original condition is repeated after repair?
Technical sources
Continue investigating
Model-specific real technical data · Measurement references · Technical diagnostic atlas