Diagnostic services
Defined request and response operations let a tester change sessions, read data, inspect faults, execute routines, control communication, or support programming workflows.
Vehicle Diagnostics Guide
UDS Diagnostics
A practical overview of how Unified Diagnostic Services fits into ECU diagnostics, transport, diagnostic sessions, data identifiers, DTC handling, testing, and engineering workflows.
Engineering model
How UDS fits together
Unified Diagnostic Services defines application-level requests and responses used by a tester to interact with an ECU. A working diagnostic workflow also depends on addressing, transport, the underlying network, ECU state, diagnostic data, and the test environment. The useful engineering model is therefore a connected stack, not a list of service identifiers in isolation.
Core concepts
The parts of a practical UDS setup
Diagnostic sessions
An ECU session controls which services and timing behavior are available. A request can be correctly formed yet invalid in the current session.
Data Identifiers (DIDs)
DIDs identify diagnostic data records. Correct interpretation depends on the ECU implementation and diagnostic database, including data layout, scaling, and access conditions.
Diagnostic Trouble Codes (DTCs)
DTC services expose fault records and status maintained by ECU diagnostic software. They support investigation but do not themselves detect the physical or software fault.
Routine Control
Routine Control starts, stops, or requests results from ECU-defined routines, usually with explicit session, security, and operating-condition prerequisites.
Protected operations
Security Access and related safeguards restrict sensitive diagnostic operations. Authorization does not replace other session, sequence, or vehicle-state conditions.
Transport
UDS application messages can be carried through ISO-TP on CAN or through DoIP on Ethernet. Each transport adds its own addressing, segmentation, timing, and routing concerns.
Diagnostic tooling
Tools such as CANoe combine diagnostic databases, request execution, network traces, test modules, and automation so behavior can be reproduced and validated.
1. Where UDS fits in the diagnostic stack
UDS specifies the diagnostic application conversation; it does not replace the transport and network layers beneath it.
Diagnostic application
↓
UDS request / response
↓
ISO-TP or DoIP
↓
CAN / Ethernet
↓
ECUWhen a diagnostic exchange fails, the first engineering task is to locate the failing layer. An unanswered UDS request may originate in ECU availability, network routing, transport configuration, addressing, session state, or the service implementation itself.
2. Diagnostic communication model
A tester sends a service request to an ECU, and the ECU returns a positive response, a negative response, or no observable response.
| Element | Engineering role | Typical question |
|---|---|---|
| Tester | Constructs requests and evaluates responses | Is the correct channel and target configured? |
| ECU | Implements services and maintains diagnostic state | Is it powered, awake, and in the required session? |
| Addressing | Selects one ECU or a functional group | Do request and response addresses match the architecture? |
| Transport | Carries messages across CAN or IP | Were segmentation, timing, and routing completed? |
| Diagnostic data | Defines supported services and data interpretation | Does the database match this ECU software variant? |
A response must be interpreted in the context of the requested service, addressing mode, active session, prior requests, and current ECU or vehicle state. The same payload can be valid in one workflow and rejected in another.
3. Common diagnostic service groups
Practical diagnostic applications organize services by engineering purpose rather than treating every service as an isolated command.
- Session control and ECU reset establish or change diagnostic operating state.
- Data read and write services exchange ECU parameters identified by the implementation and diagnostic data.
- DTC services read, filter, interpret, or clear stored diagnostic fault information.
- Routine services execute ECU-defined procedures and return status or results.
- Communication-control services influence selected ECU communication behavior under defined conditions.
- Programming-related services coordinate download, transfer, verification, and reset steps in an ECU-specific sequence.
4. DIDs and vehicle data
A DID identifies a diagnostic data record, while the ECU and diagnostic description define what its bytes mean.
- 01
Select the data identifier
Use diagnostic data that matches the ECU software and variant to identify the intended record.
- 02
Send the supported request
Construct the service payload with the correct DID and any session or access prerequisites.
- 03
Validate the response payload
Confirm the service and identifier, then decode length, byte order, scaling, units, and enumerations from the diagnostic definition.
A DBC describes CAN messages and signals; it is not a substitute for an ODX or OEM diagnostic definition. Diagnostic payload interpretation and normal network-signal decoding are related engineering activities with different data models.
5. DTC workflows
The ECU's diagnostic software detects and stores fault information; UDS provides services for accessing and managing that information.
- 01
Reproduce or observe the condition
Capture the vehicle state, network evidence, and operating conditions associated with the reported behavior.
- 02
Read DTCs and status information
Query the supported records and retain status, occurrence context, and available snapshot or extended information.
- 03
Correlate the evidence
Relate stored fault information to measurements, network traces, ECU logs, and the system's fault-detection logic.
- 04
Clear only with intent
Clear diagnostic information when the test plan calls for it, then verify whether the condition and code return.
6. Transport: ISO-TP and DoIP
The UDS application concept remains request and response based, while the communication path changes with the vehicle architecture.
| Path | Underlying network | Transport concerns |
|---|---|---|
| UDS over ISO-TP | CAN or CAN-FD | CAN identifiers, addressing mode, segmentation, flow control, padding, and timing |
| UDS over DoIP | Automotive Ethernet / IP | Discovery, logical addresses, routing activation, TCP connectivity, and gateway paths |
A diagnostic application should keep service-level intent separate from transport-specific configuration. During debugging, however, traces from both layers are needed to distinguish an ECU service response from a transport or routing failure.
7. Testing and automation
Repeatable diagnostic tests validate positive responses, negative-response behavior, timing, session transitions, and recovery across software versions.
- Build test cases around explicit preconditions, requests, expected responses, timing, and cleanup.
- Validate both supported behavior and intentional rejection paths, including the returned negative response code.
- Use CANoe and CAPL where they fit the existing network, diagnostic, simulation, and test environment.
- Preserve request and response traces so a failed assertion can be investigated at application and transport layers.
- Run stable test cases in regression suites and separate infrastructure failures from ECU behavior.
Given: ECU is available in the required vehicle state
And: diagnostic addressing and transport are configured
When: the tester sends a defined service request
Then: validate response type, payload, timing, and resulting ECU stateEngineering pitfalls
Common mistakes
Debugging UDS before verifying communication
A missing ECU, wrong network state, or broken route cannot be resolved by changing the diagnostic service payload.
Using the wrong addressing configuration
Physical and functional requests, response identifiers, and DoIP logical addresses must match the actual architecture and tester configuration.
Ignoring session and sequence prerequisites
A supported service may still be unavailable before the correct session, security level, vehicle condition, or preceding request.
Treating every negative response as a generic failure
The NRC is structured evidence about why the ECU did not provide the expected positive response and should guide the next check.
Assuming transport is already correct
ISO-TP and DoIP configuration can fail independently of UDS service logic, so transport evidence needs its own validation.
Mixing DBC and diagnostic database responsibilities
DBC data describes CAN messages and signals; diagnostic databases describe services, identifiers, parameters, and diagnostic interpretation.
FAQ
UDS questions
- Is UDS tied only to CAN?
- No. UDS defines application-level diagnostic services. It is commonly transported over CAN using ISO-TP and can also operate over Ethernet through DoIP.
- Is a DID the same as a CAN signal?
- No. A DID identifies diagnostic data exposed through a UDS service, while a CAN signal is a field encoded in a network message, commonly described by a DBC.
- Does UDS detect vehicle faults?
- UDS provides services for reading and managing diagnostic information. Fault detection and DTC storage are implemented by ECU diagnostic software.
- Why should diagnostic tests include negative responses?
- Negative responses verify that the ECU rejects invalid requests or unmet conditions in a defined way, and they provide useful evidence when a positive response is not expected.
Engineering support
Need help implementing or testing UDS diagnostics?
I can help with diagnostic communication, ECU and network traces, CANoe-based tests, automation, or a focused investigation of a failing workflow.