# PDX (Packaged ODX) > PDX (Packaged ODX) is the exchange container defined with ODX in ISO 22901-1: a ZIP archive that bundles the ODX files of one or more ECUs, for example the diagnostic layer (ODX-D), communication parameters (ODX-C), flash data (ODX-F) and vehicle information (ODX-V), together with an index catalog. OEMs hand PDX packages to tool vendors and testers so that the complete diagnostic description arrives as one file instead of a folder of XML. A PDX file is a ZIP container that packages ODX diagnostic data (ODX-D, ODX-C, ODX-F and more) with a catalog, per ISO 22901-1. What is inside and how testers use it. Source: https://auto-st.com/glossary/pdx ยท Updated: 2026-10-07 ## What is PDX? PDX (Packaged ODX) is the container format in which ODX diagnostic data is exchanged. It is a ZIP archive with a fixed structure: an `index.xml` catalog that lists every file in the package, and the ODX files themselves, each with an extension that names its category. The diagnostic layer files (`.odx-d`) describe the ECU's sessions, services, data identifiers, routines and security levels; the communication parameter files (`.odx-c`, `.odx-cs`) describe addressing and timing on CAN or DoIP; `.odx-f` carries flash data, `.odx-v` vehicle information, `.odx-e` ECU configuration and `.odx-fd` the function dictionary. Java jobs for complex sequences travel as `.jar` files inside the same package. The point of PDX is that a complete diagnostic description for one ECU or a whole vehicle arrives as one file with a checkable table of contents, rather than as a folder of loose XML that may be inconsistent. ## Where is it defined? PDX is defined together with ODX in ISO 22901-1, the ISO publication of the ASAM MCD-2 D standard. ODX 2.2.0 is the version most tools exchange today. What the data describes is UDS per ISO 14229-1: the service identifiers, sub-functions, DIDs and RIDs an ODX-D layer lists map one to one onto the requests a tester sends. ## What it means in practice For a security tester a PDX is the most useful input an OEM can provide, because it answers the questions enumeration otherwise has to guess at: which sessions exist and how they are entered, which security level each service needs, which DIDs are identification data and which are calibration, and which routines exist with which payloads. A DID list from a PDX turns a scan result from "`0xF18C` answers in default session" into "the ECU serial number is readable in default session", which is correct, and "`0xF18C` is writable without SecurityAccess", which is a finding. Two things catch people out. A PDX often describes a variant family, with several ECU variants in one package that differ in supported DIDs, so the tester has to pick the variant that matches the sample on the bench. And PDX packages are frequently generated from a CDD or from an OEM authoring database, so inconsistencies between the package and the real ECU are common and are themselves worth recording: a service the file says needs SecurityAccess and the ECU grants without it is exactly what a verification report should state. ## How AutoST tests it AutoST imports PDX packages as well as ODX, ODX-D and Vector CDD files, picks the diagnostic layers out of the package and normalises them into DIDs and routines attached to the ECU. The names enrich enumeration results, routines (0x31) are called only when the package defines them, and the optional write probing (0x2E) checks whether DIDs the file marks as protected are in fact protected. The package stays on your instance and is reused by every later scan. ## Common misunderstandings A PDX is not a flash file, although it can contain one, and it is not a test specification. It is the manufacturer's statement of what the ECU should offer. A security test compares that statement with what the ECU actually does; the differences are the result. ## FAQ **Can I just unzip a PDX?** Yes. A PDX is a plain ZIP archive. Inside you find an index.xml catalog and the ODX files, each with a category-specific extension such as .odx-d or .odx-c. Any ODX-capable tool reads the package directly; unzipping is only needed if you want to inspect the XML by hand. **Does a PDX contain the seed/key algorithm?** Normally not. ODX can reference a Java job (a .jar inside the package) for SecurityAccess, which may implement the key calculation, but most OEMs keep the algorithm out of the package. The PDX tells you which security levels exist, not how to unlock them. **Which PDX content does a security test need?** The ODX-D layers: they carry the sessions, services, DIDs, routines and security levels. ODX-C is needed to get the addressing and timing right over CAN or DoIP. Flash containers (ODX-F) are only relevant if reprogramming is in scope. ## Sources - [ISO 22901-1:2008 Road vehicles, Open diagnostic data exchange (ODX), Part 1: Data model specification](https://www.iso.org/standard/41207.html) - [ASAM MCD-2 D (ODX) standard page](https://www.asam.net/standards/detail/mcd-2-d/) - [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) - [CDD (CANdela Diagnostic Description)](https://auto-st.com/glossary/cdd) - [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/pdx