UDS / vehicle diagnostics

UDS (Unified Diagnostic Services, ISO 14229) is the standard protocol for communicating with vehicle ECUs for diagnostic purposes: reading and clearing fault codes (DTCs), reading live data, running actuator tests, and reprogramming ECU software. It runs over CAN or automotive Ethernet (via DoIP, diagnostics over IP) and is implemented in effectively every modern vehicle.

The protocol follows a client-server model: a tester — a workshop device, a factory test station, or increasingly a backend service — sends requests to an ECU, which answers with data or a negative response code. That simple pattern, standardized across the industry, is what allows one diagnostic ecosystem to serve every brand of vehicle and every supplier’s ECUs.

What UDS specifies

ISO 14229 defines a set of diagnostic services, each identified by a one-byte service ID. The most used cover reading and writing data by identifier, reading and clearing stored DTCs together with their freeze-frame data, controlling actuators and running ECU-internal routines, and the session and security mechanisms that gate access. An ECU normally sits in a default session with limited capabilities; a tester can request an extended session for deeper functions or a programming session for reflashing, and sensitive operations are protected by challenge-response security access and, in newer implementations, certificate-based authentication.

Reprogramming is the highest-stakes use. UDS defines the download services through which a complete software image is transferred to an ECU, and Classic AUTOSAR ECUs are updated exactly this way — which is why the same protocol family underpins both the workshop flash tool and parts of the OTA update chain. What the standard deliberately does not define is meaning: which data identifiers and DTCs an ECU implements is left to OEMs and suppliers, described in machine-readable exchange formats such as ODX and consumed by diagnostic tooling. UDS standardizes the grammar of diagnostics; the vocabulary remains proprietary.

Transport: CAN, DoIP and the gateway problem

UDS is transport-independent by design. On classical networks it runs over CAN using the ISO 15765 transport layer (DoCAN), which segments diagnostic messages into CAN frames. For Ethernet-based access, ISO 13400 defines DoIP, which carries the same diagnostic payloads over IP — with vehicle discovery, routing activation, and enough bandwidth to make flashing large ECU images practical. DoIP has become the standard workshop and factory interface for vehicles with Ethernet-capable gateways, with the gateway routing requests onward to ECUs on internal buses.

Centralized E/E architectures raise the stakes of that routing role. When functions consolidate onto central computers and zone controllers, diagnostic access to every logical function must still work through standardized interfaces, because workshop tooling, test equipment and legal access regimes all assume it. Preserving the external diagnostic contract while the internal architecture changes underneath it is one of the quiet engineering burdens of the SDV transition.

Where diagnostics carries the vehicle lifecycle

Diagnostics is a quietly load-bearing part of the SDV stack. Workshop tooling, end-of-line testing in the factory, OTA update verification and fleet health monitoring all depend on the same diagnostic services and data definitions. An ECU’s diagnostic implementation is exercised from the first factory test to the last workshop visit: production lines use UDS to configure and verify ECUs, update systems use it to flash and to confirm software state, and field-quality teams rely on the DTC and snapshot data it delivers. Few automotive software investments are amortized over as many phases of the vehicle’s life.

Diagnostics and regulation

Two regulatory threads run through diagnostics. The first is access: emissions-related on-board diagnostics (OBD) is a legally mandated regime with standardized connectors and data, and broader repair-and-maintenance legislation in several markets obliges manufacturers to give independent workshops access to diagnostic information — a debate that continues around telematics data and the EU Data Act. The second is security: diagnostic interfaces are among the most attractive attack surfaces on a vehicle, since they are designed to read internal state and rewrite software. The UNECE R155 cybersecurity regime expects manufacturers to manage exactly this risk, and the engineering processes of ISO/SAE 21434 treat diagnostic access, security access mechanisms and reprogramming paths as core items for risk assessment. Diagnostics thus sits in a structural tension between mandated openness and mandated protection.

The service-oriented shift: SOVD

UDS was designed for ECUs whose software is a fixed image. High-performance computers running dozens of updatable applications fit that model poorly, which is why ASAM standardized SOVD (Service-Oriented Vehicle Diagnostics) in the early 2020s: an HTTP- and API-based diagnostic interface designed for exactly these machines, covering apps and their logs alongside classical fault data. SOVD is positioned as a complement, not a replacement — it can front classical UDS ECUs through a gateway while offering modern access to the computers above them. How quickly tooling ecosystems adopt it is one of the practical questions of the next few years.

Current state as of 2026 and what to watch

The current shift is remote: cloud-connected diagnostics moves fault analysis from the workshop bay to the backend, enabling predictive maintenance and over-the-air triage — while raising exactly the access-control questions the R155 regime must answer. UDS itself is not going anywhere; its installed base and regulatory embedding make it the most durable protocol in the vehicle. What to watch is the layer above it: SOVD adoption on central computers, the security architecture around remote diagnostic access, and whether aftermarket access rules keep pace with architectures in which the diagnostic port is no longer where the data lives.