SOVD vs UDS: diagnostics for the software-defined vehicle

SOVD, Service-Oriented Vehicle Diagnostics, is a diagnostics API standardised by ASAM. Version 1.0.0 was published on 30 June 2022, and the standard is being carried into ISO as the ISO 17978 series on service-oriented vehicle diagnostics. Rather than a new wire protocol, it defines a uniform, web-style interface to a vehicle's diagnostic content across the whole lifecycle: development, end-of-line, the workshop and the cloud.

Technically it is built on familiar IT foundations: HTTP and REST, with JSON payloads, and authentication and authorisation based on OAuth 2.0 and OpenID Connect. The available capabilities — faults, measurements, configuration and software-update functions — are self-described through an OpenAPI specification, so a client can discover what a target offers at runtime instead of relying on a pre-shipped, statically packaged description. That is a deliberate fit for high-performance computers (HPCs), zonal and service-oriented E/E architectures, vehicle apps, and uniform remote or over-the-air access.

UDS, Unified Diagnostic Services, is defined in ISO 14229, with the data-link-independent application layer in ISO 14229-1:2020. It is the workhorse of off-board diagnostics: a request and response protocol of services, each identified by a single-byte Service Identifier, carried over transports such as DoCAN (ISO 15765-2) on CAN and CAN FD, or DoIP (ISO 13400) over automotive Ethernet. It was engineered for resource-limited ECUs and tightly constrained bus bandwidth, and it does that job extremely well.

The strain shows when the thing being diagnosed is no longer a small, fixed-function ECU. A high-performance computer running containers, services and frequently updated applications does not map cleanly onto a static, byte-oriented, ECU-centred model. Application-level faults, log access, dynamic content and uniform remote access are awkward to express in UDS, and every diagnostic description has to be authored and shipped ahead of time. That mismatch, not any deficiency in UDS itself, is what SOVD is designed to address.

The most important point for any planning team is that SOVD is not a rip-and-replace of UDS. It is positioned as a layer above the vehicle that presents one uniform API to clients, whether the target is a modern HPC served natively or a classic ECU still speaking UDS underneath. In practice an adapter or translation function fronts the legacy estate, mapping SOVD requests down to UDS (and protocols such as J1939 or KWP) so existing control units remain fully reachable through the new interface.

The practical consequence is that the millions of UDS-based ECUs already in service, and the authoring, tooling and production processes around them, keep working. SOVD becomes the consistent front door; UDS remains the language spoken to the parts of the vehicle that were built to speak it. Migration becomes incremental rather than a cliff edge.

Start with the architecture question, not the protocol question. SOVD pays off where there is service-oriented compute, OTA, app-level behaviour or remote diagnostics to expose; a deeply embedded ECU on CAN gains little from being re-fronted and is best left on UDS behind the adapter. Map your estate into native-SOVD targets and legacy targets first, then decide where the translation boundary sits.

Two areas deserve early attention. Security moves from a bus-trust model to web-grade identity: OAuth 2.0 and OpenID Connect mean role and token management, certificate handling and an HSM-backed trust anchor become part of the diagnostic design, not an afterthought. And data semantics must stay coherent across both worlds, so a fault, a data identifier or an update state means the same thing whether it arrived natively over SOVD or was translated up from UDS. Getting that mapping right is where most of the real engineering effort lands.

SOVD is best understood as diagnostics catching up with the software-defined vehicle. As function moves into HPCs and is updated continuously over the air, the diagnostic interface has to become discoverable, service-oriented and remotely accessible, while still reaching the embedded ECUs that will populate vehicles for a long time yet. SOVD over the top, UDS underneath, is the shape that lets both coexist.

This is the territory Diadrom works in daily: off-board authoring and test with Diag Studio, on-board UDS communication with the Diag Com Stack, and an HSM-based security layer for the trust SOVD assumes. We have published our view on taming the software-defined vehicle with diagnostics, and the consistent message is that the value lies in bridging the new and the installed base coherently rather than betting the programme on a single standard.