SOVD – Service-Oriented Vehicle Diagnostics

Service-Oriented Vehicle Diagnostics (SOVD) redefines vehicle diagnostics. Instead of providing diagnostic data and functions via traditional diagnostic protocols, SOVD makes them available as digital services, thereby laying the foundation for modern, software-centric vehicle architectures. In comparison to established standards such as UDS (ISO 14229) or MCD (ISO 22900-3), SOVD utilizes modern web technologies and communication standards specified in ISO 17978.

Additionally, the standardized interface facilitates seamless integration with backend systems, cloud platforms, and digital service environments. At the same time, SOVD supports innovative technologies such as the Internet of Things (IoT), big data analytics, and artificial intelligence (AI). Companies thus benefit from more efficient diagnostic processes, greater scalability, and a future-proof foundation for the Software-Defined Vehicle (SDV).

The driving force behind modern vehicle diagnostics

The development of software-defined vehicles (SDVs) is advancing rapidly. The increasing adoption of electric vehicles (EVs) and the integration of apps and digital services are driving new demands for vehicle diagnostics. In the future, diagnostics will need to encompass not only traditional electronic control units (ECUs) but also apps and vehicle functions implemented as software.

This is where SOVD can provide a valuable solution. The standard establishes a consistent and forward-looking diagnostic interface, offering standardized diagnostic functions across all vehicle models. As modern vehicles are expected to feature a combination of existing electronics and new centralized systems in the coming years, SOVD provides a uniform, standardized API that reliably covers all relevant diagnostic use cases, regardless of the vehicle generation.

Additionally, the high-performance computers (HPCs) installed in the vehicle enable comprehensive diagnostics to be performed directly within the vehicle for the first time. The standardized SOVD API enables the secure, service-oriented, real-time availability of diagnostic data. This results in a diagnostic architecture that meets the requirements of both current transitional generations and future SDV platforms.

A Perfect Match: SOVD and Our HPC Solutions

ACTIA is expanding the capabilities of modern vehicle diagnostics by making the SOVD server available not only on our HPCs (high-performance computers) but also in our telematics systems and our VCIs.

Request now

Main features & highlights

SOVD integrates all data relevant to diagnostics into a vehicle and defines an API to access diagnostic functions and perform diagnostic actions.

SOVD defines the standardized procedures for accessing the diagnostics
– Co-Located, Remote, In-Vehicle.

Both traditional electronic control units (ECUs) and modern apps can be diagnosed using SOVD and integrated into future-oriented SDV (Software-Defined Vehicle) architectures.

SOVD defines a standardized procedure for protecting and accessing data using authorization and authentication via OpenID and OAuth 2.

Use cases

Despite the technical feasibility, access to the vehicle network requires structured protocols and distinguishes between different use cases:

  • In-Vehicle
    via an app/function in the vehicle
  • Remote
    via a remote connection to the cloud
  • Co-Located
    Repair case, handled by diagnostic experts

The SOVD standard deliberately does not define any fixed network channels, allowing OEMs to continue using their existing infrastructure. At the same time, the authentication and authorization concept embedded in the standard provides secure and controlled management of diagnostic access. In this way, SOVD enables role-based provisioning of diagnostic functions and ensures the protection of sensitive vehicle data in accordance with modern security standards.

Software update

The SOVD standard facilitates flexible software update management, independent of individual control units or specific vehicle components. This feature enables the centralized and efficient updating of software versions for both individual components and multiple entities, such as apps, functions, or entire vehicle systems.

The SOVD server registers the required software packages and then activates them in a controlled manner within the vehicle. Furthermore, users can track the status of an update at any time and monitor its current progress and successful completion via standardized status queries. SOVD establishes the basis for secure, scalable, and future-proof software updates in modern software-defined vehicles (SDVs).

Development of the SOVD standard at ASAM/ISO

The ASAM SOVD specification defines a standard that covers all vehicle diagnostic tasks while taking current challenges into account. It primarily focuses on standardized access to the SOVD servers located in the vehicle. Conventional ECUs are supported through the use of the CDA (Classic Diagnostic Adapter) specified in the SOVD standard.

  • SOVD has been developed as a standard at ASAM e.V. since 2019
  • SOVD was submitted to ISO as ASAM Version 1.0 as NWIP and adopted as a new ISO standard
  • SOVD was submitted to ISO as ASAM version 1.1 at the end of 2024 and will undergo the usual process and be published as ISO 17978.

Experts from ACTIA IME GmbH contributed to the development and design of the SOVD standard through a working group of ASAM e.V. (Association for Standardization of Automation and Measuring Systems), and they remain active members of the working groups. In parallel with the development of the specification at ASAM, ACTIA is developing its own SOVD server, which will complement ACTIA’s portfolio of ISO diagnostic standards for the automotive industry.

  • Technical details
  • SOVD at ACTIA

Technical details

Entity concept

All diagnostic endpoints in the vehicle are mapped via the entity concept in the SOVD standard.

Entities are:

  • the SOVD server itself,
  • Components (comparable with classic ECUs)
  • APPs (software components of any kind)
  • Areas (grouped areas, e.g. formerly the PowerTrain)
  • Functions (functionally related entities -> requests that address multiple entities, e.g. vehicle health)

Resource concept

Each entity provides its diagnostic functionality via resources; these are defined in the SOVD standard 1.1:

  • Data Read/Write
  • Fault handling
  • Configuration
  • Operations
  • Handling of Bulk Data
  • Restart
  • Support of Target Modes
  • Software update
  • Clearing Data
  • Locking
  • Cyclic subscriptions
  • Triggers
  • Script Execution
  • Logging

Capability description

The diagnostic functionalities available in an SOVD server are provided via the capability description. These are available in two central versions:

  • Offline Capability Description:
    This includes a comprehensive diagnostic description of a vehicle class, including all variants and installation options, and makes it available to a diagnostic author.
  • Online Capability Description:
    This includes precisely those diagnostic data descriptions that are available for the specific vehicle variant, including the software versions and configurations active in that variant.
    In other words, the SOVD server in the vehicle knows its exact status and provides the appropriate diagnostics. This eliminates the time-consuming variant handling that was previously common and necessary.
    This description is marked as “optional” in the standard and can be specifically and precisely requested for the resource/entity.
  • Optionally, when making requests to a resource, you can request the underlying schema. This schema describes the exact structure of the returned resource.

Modern REST/JSON based API

Unlike traditional diagnostics, where diagnostic queries had to be extensively structured and parameterized and the diagnostic responses had to be evaluated with considerable effort, the SOVD API is provided using modern web technologies.

A diagnostic request is sent to the SOVD server via a REST request; a simple GET REST request is comparable to calling up a URL in a browser (e.g., http://sovd.actia.de/v1.0/components). In this case, the ACTIA SOVD Demo Server would return the list of available component entities. REST requests are described using OPEN-API, a standard for describing APIs that evolved from Swagger. In REST—and thus also in SOVD—it is possible to execute requests as GET (retrieve information), PUT/POST (send information), and DELETE (delete information).

The response from the SOVD server is in JSON format, which can be processed by both SOVD clients and any standard browser.

Discovery

SOVD servers include the capability to dynamically announce and discover their presence within a network. This means that a diagnostic client can use mDNS (Multicast DNS) to identify whether one or more SOVD servers are available and how they can be reached.

SOVD at ACTIA

ACTIA is developing its own SOVD server in parallel with the creation of the specification at ASAM, which completes ACTIA’s portfolio of ISO diagnostic standards for the automotive industry.

The ACTIA SOVD Server is based on an architecture that enables its use with a lightweight UDS client, as well as in various configurations up to the full integration of a D-Server or an OTX runtime. For this purpose, it utilizes the CDA (Common Diagnostic API) defined within the SOVD standard. The SOVD-OTX Extension, which is currently being developed by ASAM as part of ISO 13209, will become an integral part of the OTX runtime in the future, enabling it to access the SOVD API and, consequently, applications (apps).

In parallel, apps can be accessed through the SOVD API using flexible interfaces. At present, there are no standardized interfaces or diagnostic capabilities for apps. ACTIA’s concept therefore lays the foundation for the integration of customer-specific applications.

The following image shows an example of the integration of a complete diagnostic stack into the SOVD server.

This integration makes it possible to reuse stable diagnostic protocols that have been tried and tested in practice for years, especially in order to support special control units or protocols that will still exist in the coming years, parallel to the modern architectures. In addition, extensive automatic data conversion, e.g. from ODX to SOVD capability, ensures that the new technology can be used relatively quickly.

Although the SOVD standard is primarily intended for in-vehicle diagnostics, ACTIA will also offer its SOVD server in its Vehicle Communication Interfaces (VCIs) in the future, in addition to deployments on HPCs and telematics units. This will ensure a consistent diagnostic experience, particularly in transition scenarios.

Our SOVD expert

Torsten Eschner
Product Management

Expert profile at ASAM

Contact us
Scroll to Top