UDS / DoIP vehicle diagnostics basics
UDS (Unified Diagnostic Services, ISO 14229) is the common set of diagnostic services for automotive ECUs. Reading fault codes, reading and writing parameters, running routines, and reflashing firmware are all expressed with unified service IDs.
Contents
UDS is a set of services
In UDS, each task has its own SID (Service Identifier). Typical ones are Diagnostic Session Control (10h), ECU Reset (11h), Security Access (27h), Read Data By Identifier (22h), Write Data By Identifier (2Eh), Read DTC Information (19h), Routine Control (31h), Request Download (34h), and Transfer Data (36h).
The ECU either accepts the requested service or rejects it with a negative response (7Fh) and an NRC (Negative Response Code) giving the reason. Implementation bugs tend to show up in how NRCs are used.
Sessions and security
UDS has the concept of diagnostic sessions. Only limited services are available in the default session; writing and reprogramming become possible only after moving to the extended or programming session.
In addition, Security Access (27h) is required before dangerous operations. The ECU issues a seed and unlocks only if the correct key is returned. In practice, managing and distributing this key algorithm is a thornier issue than the design itself.
Data longer than 8 bytes — ISO 15765-2
When UDS runs on CAN, messages longer than 8 bytes are segmented with ISO 15765-2 (CAN-TP, ISO-TP), using four frame types: single frame (SF), first frame (FF), consecutive frame (CF), and flow control (FC).
The flow-control block size (BS) and minimum separation time (STmin) directly affect transfer time. If reprogramming takes longer than expected, check these first.
DoIP — diagnostics over Ethernet
DoIP (Diagnostics over IP, ISO 13400) carries diagnostics over automotive Ethernet. Large firmware transfers that are impractical at CAN bandwidth finish orders of magnitude faster.
DoIP proceeds through vehicle identification, routing activation, and then sending and receiving diagnostic messages. The easiest way to think of it: the UDS services are the same as on CAN, and only the lower-layer transport changes.
In practice, it is common to keep CAN diagnostics and DoIP side by side and choose the route by target ECU and data volume.
ODX and A2L — which database for what
ODX (ISO 22901) is the standard format for diagnostic information: which services each ECU has and what each DID means, in machine-readable form. A packaged version for distribution is a PDX.
A2L (ASAM MCD-2 MC) is the file for measurement and calibration (XCP/CCP). It describes the addresses, conversion formulas, and characteristic maps of ECU internal variables.
The two serve different purposes: ODX for diagnostics, A2L for measurement and calibration. When choosing tools, first check which format your existing assets are in.
Where it is used in each development stage
Early in development, fixing the diagnostic specification with ECU simulation reduces rework. When hardware becomes available, capture diagnostic logs and compare them with the specification. Before production, verify programming time with parallel flashing. For service, you need diagnostic tools customized for the field.
Using a different vendor's tool at each stage means wasting effort converting ODX assets. Whether you can standardize on one tool family is worth checking during selection.
Frequently asked questions
- How does UDS differ from OBD?
- OBD is legally mandated emissions diagnostics that any generic external scan tool must be able to read, whatever the vehicle. UDS is a diagnostic system that manufacturers define freely and use in development, production, and service. In practice, the same ECU usually answers both.
- If we move to DoIP, do we still need CAN diagnostics?
- Normally the two coexist. Not every ECU is on Ethernet, and existing service processes often assume CAN. In your migration plan, decide on tools that handle both and on how routes will be switched.
- Can you help us set up a diagnostic environment?
- Yes. Tell us the protocols and versions, your existing ODX/A2L assets, and the stages involved (development, production, service), and we will propose a configuration.
Related product categories and solutions
- Automotive ECU diagnostics, measurement, and calibration (product category)
- Middleware / protocol stacks (product category)
- Flash programming / production programming (product category)
- Automotive ECU diagnostics, measurement, and calibration (UDS / XCP / OBD) (solution)
- Commercial, construction, and agricultural vehicles (SAE J1939) (solution)
Other technical guides
- How to choose an embedded RTOS
- CANopen basics — CiA 301 / 302 / 402 and how to develop CANopen devices
- SAE J1939 basics — CAN for commercial, construction, and agricultural vehicles
- Embedded debugging and trace basics
- Designing production programming — cycle time, gang programming, and IP protection
- Automotive Ethernet basics — 100/1000BASE-T1, time sync, and measurement
- LIN basics — ISO 17987, LDF, and conformance testing
- What is functional safety? — an introduction to ISO 26262 / IEC 61508
Look up the terms
Discuss your setup
If you organize your requirements along the lines of this guide, we can reply early with a proposed configuration and a rough estimate. Partial questions are welcome too.