top of page
Search

OTX and SOVD

  • Writer: Jörg Supke
    Jörg Supke
  • Oct 28
  • 7 min read

Updated: Oct 29

ree

SOVD is more than just a new diagnostic interface – it marks a paradigm shift in vehicle diagnostics. While previous diagnostic systems were characterized by technical limitations, the approach of providing diagnostic functions as web services opens up entirely new possibilities for efficiency, integration, and innovation. The combination of OTX and SOVD unites standardized diagnostic logic with modern, service-oriented vehicle communication. This article introduces SOVD and the new SOVD extension for OTX and demonstrates how future-oriented application scenarios can be derived from them.


Contents


What is SOVD?

The increasing digitalization and networking of modern vehicles require new concepts for diagnostics, maintenance, and service. The "Service-Oriented Vehicle Diagnostics" (SOVD) standard provides a future-oriented solution for making diagnostic processes more efficient, flexible, and secure. SOVD is a standardized, service-based diagnostic interface (API) based on modern web technologies such as HTTP(S), REST, and JSON. It was developed within the framework of ASAM to enable cross-manufacturer, IP-based communication with vehicle components (ISO/DIS 17978). The diagnostic functions are provided as web services, which significantly facilitates integration into tools, cloud systems, and mobile applications.


Figure 1: SOVD Architecture
Figure 1: SOVD Architecture

The data model is dynamic and service-oriented. Clients can query at runtime which entities are available, which resources they contain, and which actions are possible. SOVD distinguishes three basic types of clients, which differ in their physical proximity to the vehicle and their intended use (see Figure 1 ).


  1. Proximity client

    The proximity client is physically located near the vehicle and is connected directly to the vehicle network – e.g., via Wi-Fi or Ethernet. Examples include workshop equipment, diagnostic tools, and engineering tools. They typically have a wide range of functions and direct access to all available diagnostic data.

  2. Remote Client

    The remote client accesses the SOVD server in the vehicle remotely via a secure connection (e.g., VPN or cloud API). Typical applications include fleet management systems, remote diagnostic portals, or OEM backend systems. These often use restricted permissions, such as read-only access or event subscriptions.

  3. In-Vehicle Client

    The in-vehicle client runs directly in the vehicle, for example, as part of a domain controller, gateway, or diagnostic module. It uses the SOVD interface for internal communication, for example, for self-diagnosis, monitoring, logging, or securing OTA processes.


The clear separation of client types allows for differentiated rights management, network architecture and security strategy – depending on the application scenario and user role.


The SOVD data model is based on a structured, hierarchical representation of vehicle-relevant information. The data is transmitted in the form of JSON objects, which allow for easy processing and interpretation. The data model consists of the following hierarchically structured entities, see Figure 2 :


  1. server

    Represents the SOVD server itself. It manages sessions, accesses, events, and provides the central entry point structure for clients.

  2. Area

    Represents a logical area within the vehicle, e.g., Driving, Powertrain, Infotainment, or Chassis. Serves to group and structure components.

  3. Component

    A functional or physical unit (hardware or software), e.g., an ECU or a software subsystem. Components are assigned to areas. Only software components or components with software components link to apps.

  4. App (Application)

    A software application or logical function within a component, such as advanced lane keeping or window control. Apps are assigned to components.

  5. Function

    A function provides a general, functional interface and enables the definition of any manufacturer-specific diagnostic functions, which can also be distributed across multiple components, e.g., vehicle identification. SOVD does not describe further details here. For consistent standardization, it is advisable to implement the functions using standardized OTX procedures.


Figure 2: SOVD entities
Figure 2: SOVD entities

Advantages of SOVD:


  1. Standardization and interoperability

    SOVD follows an open standard that enables vendor-independent implementations. This makes it easier for tools, services, and control units from different manufacturers to work together.

  2. Web technology instead of binary protocol

    Using JSON and HTTP(S) makes development and debugging significantly easier than with traditional protocols like UDS. Developers benefit from familiar tools and libraries from web development.

  3. Remote diagnostics and OTA capability

    SOVD enables communication over IP-based networks. This enables remote diagnostics and vehicle maintenance—a decisive advantage for connected services, fleet management, and over-the-air updates.

  4. Live data and event notifications

    In addition to classic requests, SOVD also supports the subscription model: Clients can subscribe to specific vehicle states and be actively notified of changes.

  5. Security by Design

    SOVD offers integrated security mechanisms such as authentication, encryption (TLS), and role-based access, enabling targeted security for vehicle diagnostics.

  6. Compatibility with modern development processes

    By using open interfaces, SOVD can be easily integrated into DevOps processes, CI/CD pipelines, and cloud environments.

 

Application examples:


  • Workshop diagnosis

    Intuitive web UIs access the vehicle directly via Wi-Fi or Ethernet.

  • Remote Services

    A backend system reads vehicle data and proactively creates service tickets.

  • Fleet management

    Real-time data from the vehicle fleet is aggregated and evaluated.


OTX SOVD-Extension

In the ASAM "OTX Extensions" working group, OTX was extended in mid-2025 with an SOVD and a JSON extension. The JSON extension enables the reading, interpretation, and writing of JSON data and forms the basis of the SOVD extension. The SOVD extension operates as an SOVD client and provides new data types, actions, and terms for accessing an SOVD server (see Figure 3) . The SOVD extension supports ASAM SOVD version 1.0 and ISO/DIS 17978-3. It will be expanded for new SOVD versions in the future.


Figure 3: SOVD Architecture with OTX
Figure 3: SOVD Architecture with OTX

The SOVD extension enables browsing SOVD entities and accessing resources. Resources represent the entities' diagnostic capabilities. Functions are provided to retrieve the diagnostic capabilities of each resource and to configure or execute diagnostic operations. The SOVD entity "Function" is not currently supported by the SOVD ODX extension.


The following OTL code example demonstrates the application of the SOVD extension. It determines all errors found in the first-level components and returns them as a list.


public procedure GetAllFaults(out List<SOVD.FaultDescriptor> faultList)
{
    /// Local Declarations

    List<SOVD.EntityDescriptor> servers;
    SOVD.EntityDescriptor server;
    Map<String, SOVD.EntityDescriptor> components;
    SOVD.EntityDescriptor component;
    Map<String, SOVD.FaultDescriptor> faults;
    SOVD.FaultDescriptor fault;

    /// Flow

    servers = SOVD.GetDiscoveredSovdServer();

    foreach (server in servers) : ForEachLoop1
    {
        components = SOVD.GetComponentDescriptors(server);

        foreach (component in components) : ForEachLoop2
        {
            faults = SOVD.GetFaultsAsDescriptors(component);

            foreach (fault in faults) : ForEachLoop3
            {
                ListAppendItems(faultList, {fault});
            }
        }
    }
}

OTX and SOVD - A Powerful Combination

A particularly powerful use case arises from the combination of SOVD with OTX. OTX allows standardized diagnostic sequences to be specified, implemented, tested, and exchanged and executed in any environment. The new SOVD extension for OTX enables web service-based diagnostic data to be seamlessly integrated into OTX sequences. Two application scenarios are essentially possible for the combination of OTX and SOVD, see Figure 4 .


In Scenario A, SOVD uses the OTX standard. The SOVD server launches OTX procedures in the OTX runtime. The SOVD entity "Function" is ideal for this purpose. It provides a general, functional interface for any manufacturer-specific diagnostic functions. An SOVD client in the backend could thus launch any OTX procedure via the SOVD function.


Figure 4: Application scenarios OTX and SOVD
Figure 4: Application scenarios OTX and SOVD

In Scenario B, the OTX runtime itself operates as an SOVD client. Using the new SOVD extension, virtually any SOVD function can be processed from OTX. In addition, the OTX runtime can also perform diagnostic communication via the DiagCom extension, as before, making it ideal for migration scenarios or mixed installations with control units that are not available via SOVD.


In practice, a combination of scenarios A and B is likely for the so-called on-board tester , see also Figure 5. OTX procedures are started on the OTX runtime via an SOVD client. These procedures can act as SOVD clients via the OTX SOVD extension and use the functions of the SOVD server. This scenario best combines the advantages of both worlds.


Advantages of combining OTX and SOVD:


  1. Modern communication meets structured logic

    SOVD provides the IP-based, service-oriented interface to the vehicle and OTX models the diagnostic logic in a standardized and visual manner.

  2. Reusable diagnostic workflows

    With OTX, diagnostic workflows can be specified, implemented, tested, released, exchanged, and deployed to any target system. SOVD enables the dynamic execution of these workflows via web services – locally or remotely.

  3. Independence from protocols and platforms

    OTX remains the same regardless of whether communication takes place via MVCI, SOVD, UDS, or DoIP in the backend. The runtime abstracts access via the selected communication layer.

  4. Efficient remote and cloud diagnostics

    OTX sequences can be executed remotely by SOVD (e.g., via cloud backend or mobile apps).

  5. Transparency and debugging

    The OTX runtime environment makes diagnostic processes traceable and testable. Combined with SOVD, logs, events, and statuses can be analyzed specifically.

  6. Fast integration into existing systems

    OTX can be easily integrated into existing systems. SOVD opens up modern access options without fundamental changes to the logic.

  7. Future-proof for software-defined vehicles (SDV)

    SOVD is designed for zonal architectures and distributed systems. OTX provides a stable modeling layer—independent of the vehicle architecture.


The following figure shows an example architecture for the combination of OTX and SOVD in the so-called on-board tester . For example, if a vehicle analysis is to be performed, a remote SOVD client calls a corresponding OTX procedure as an SOVD function via the SOVD server. The OTX runtime collects the data from the detected control units via SOVD and also directly via UDS (OTX's DiagCom extension). It creates the log and sends it back to the remote SOVD client via the SOVD server.


Figure 5: SOVD / OTX sample architecture (OnBoard-Tester)
Figure 5: SOVD / OTX sample architecture (OnBoard-Tester)

Tool Support

The SOVD and JSON extensions are fully supported starting with version 9 of the OTX tool chain. A user's offline capability description in JSON format can be loaded and displayed in the toolbox. Note: The offline capability description describes the data available to the user from the SOVD server.


Figure 6: OTX IDE Open Test Framework with SOVD support
Figure 6: OTX IDE Open Test Framework with SOVD support

Based on this, the user can program their OTX test logic. Checker rules verify the correctness of inputs, and a built-in SOVD server simulation allows testing the OTX process even without an available server.


Conclusion

SOVD is more than just a new diagnostic interface—it's a paradigm shift in vehicle diagnostics. While diagnostic systems of the past were limited by the lack of available resources, the approach of providing diagnostic functions as web services creates new opportunities for efficiency, integration, and innovation.


The combination of OTX and SOVD combines standardized diagnostic logic with modern, service-oriented vehicle communication. OTX enables the structured and reusable modelling of diagnostic processes, while SOVD, as an IP-based interface, offers flexible, secure, and remote access to vehicle data. Together, they enable the efficient, process-reliable development, execution, and automation of diagnostic processes – locally in the workshop, in the test field, or remotely via the cloud. OTX and SOVD are a future-proof combination in the context of software-defined vehicles and modular vehicle architectures.


bottom of page