OTX und SOVD

SOVD ist mehr als eine neue Diagnoseschnittstelle – es markiert einen Paradigmenwechsel in der Fahrzeugdiagnose. Während frühere Diagnosesysteme durch technische Einschränkungen geprägt waren, eröffnet der Ansatz, Diagnosefunktionen als Webservices bereitzustellen, völlig neue Möglichkeiten für Effizienz, Integration und Innovation. Die Kombination von OTX und SOVD verbindet standardisierte Diagnoselogik mit moderner, serviceorientierter Fahrzeugkommunikation. Der Beitrag stellt SOVD sowie die neue SOVD-Extension für OTX vor und zeigt, wie sich daraus zukunftsweisende Anwendungsszenarien ableiten lassen.

---

Inhalt

1. Was ist SOVD?

2. OTX SOVD-Extension

3. OTX und SOVD - Eine starke Kombination

4. Toolunterstützung

5. Fazit

---

Was ist SOVD?

Die zunehmende Digitalisierung und Vernetzung moderner Fahrzeuge erfordern neue Konzepte für Diagnose, Wartung und Service. Mit dem Standard "Service-Oriented Vehicle Diagnostics" (SOVD) steht eine zukunftsweisende Lösung bereit, um Diagnoseprozesse effizienter, flexibler und sicherer zu gestalten. SOVD ist ein standardisiertes, servicebasiertes Diagnoseschnittstelle (API), die auf modernen Webtechnologien wie HTTP(S), REST und JSON aufbaut. Sie wurde im Rahmen des ASAM entwickelt, um eine herstellerübergreifende, IP-basierte Kommunikation mit Fahrzeugkomponenten zu ermöglichen (ISO/DIS 17978). Die Diagnosefunktionen werden dabei als Webservices bereitgestellt, was die Integration in Tools, Cloudsysteme und mobile Anwendungen erheblich erleichtert.

Abbildung 1: SOVD-Architektur

Das Datenmodell ist dynamisch und serviceorientiert aufgebaut. Clients können zur Laufzeit abfragen, welche Entitäten verfügbar sind, welche Ressourcen sie enthalten und welche Aktionen möglich sind. In SOVD unterscheidet man drei grundlegende Arten von Clients, die sich durch ihre physische Nähe zum Fahrzeug und ihren Einsatzzweck unterscheiden, siehe Abbildung 1.

1. Proximity-Client

   Der Proximity-Client befinden sich physisch in der Nähe des Fahrzeugs und wird direkt mit dem Fahrzeugnetzwerk verbunden – z. B. über WLAN oder Ethernet. Beispiele: Werkstattgeräte, Diagnosetools, Engineering-Tools. Sie haben in der Regel einen hohen Funktionsumfang und direkten Zugriff auf alle verfügbaren Diagnosedaten.

2. Remote Client

   Der Remote-Client greift aus der Ferne über eine gesicherte Verbindung (z. B. VPN oder Cloud-API) auf den SOVD-Server im Fahrzeug zu. Typische Anwendungen sind Flottenmanagementsysteme, Remote-Diagnoseportale oder Backend-Systeme eines OEMs. Sie nutzen häufig eingeschränkte Rechte, z. B. nur Lesezugriffe oder Event-Subscriptions.

3. In-Vehicle Client

   Der In-Vehicle Client läuft direkt im Fahrzeug, etwa als Teil einer Domänensteuerung, eines Gateways oder eines Diagnosemoduls. Er nutzt die SOVD-Schnittstelle zur internen Kommunikation, zum Beispiel für Selbstdiagnose, Überwachung, Logging oder Absicherung von OTA-Prozessen.

Die klare Trennung der Client-Typen erlaubt eine differenzierte Rechteverwaltung, Netzwerkarchitektur und Sicherheitsstrategie – abhängig von Anwendungsszenario und Nutzerrolle.

Das Datenmodell von SOVD basiert auf einer strukturierten, hierarchischen Darstellung fahrzeugrelevanter Informationen. Die Daten werden in Form von JSON-Objekten übertragen, die eine einfache Verarbeitung und Interpretation ermöglichen. Das Datenmodel besteht aus folgenden so genannten Entitäten, die hierarchisch gegliedert sind, siehe Abbildung 2:

1. Server

   Repräsentiert den SOVD-Server selbst. Er verwaltet die Sessions, Zugriffe, Events und stellt die zentrale Entry-Point-Struktur für Clients bereit.

2. Area

   Stellt einen logischen Bereich im Fahrzeug dar, z. B. Driving, Powertrain, Infotainment, Chassis. Dient zur Gruppierung und Strukturierung von Komponenten.

3. Component

   Eine funktionale oder physikalische Einheit (Hard- oder Software), z. B. ein Steuergerät (ECU) oder ein Software-Subsystem. Komponenten sind den Areas zugeordnet. Nur Software-Komponenten oder Komponenten mit Software-Anteilen verlinken zu APPs.

4. App (Application)

   Eine Softwareanwendung oder logische Funktion innerhalb einer Komponente, z. B. Advanced-Lane-Keeping oder Window-Control. Apps sind Komponenten zugeordnet.

5. Function

   Eine Funktion stellt eine allgemeine, funktionale Schnittstelle bereit und ermöglicht beliebige, herstellerspezifische Diagnosefunktionen zu definieren, die auch über mehrere Komponenten verteilt sein können, z. B. Fahrzeugidentifikation. SOVD beschreibt hier keine weiteren Details. Für eine durchgängige Standardisierung bietet es sich an, die Functions über standardisierte OTX-Prozeduren zu realisieren.

Abbildung 2: SOVD-Entitäten

Vorteile von SOVD:

1. Standardisierung und Interoperabilität

   SOVD folgt einem offenen Standard, der herstellerunabhängige Implementierungen ermöglicht. Dadurch können Tools, Services und Steuergeräte verschiedener Hersteller einfacher zusammenarbeiten.

2. Webtechnologie statt Binärprotokoll

   Die Verwendung von JSON und HTTP(S) macht die Entwicklung und das Debugging deutlich einfacher als bei klassischen Protokollen wie UDS. Entwickler profitieren von vertrauten Tools und Libraries aus der Webentwicklung.

3. Remote-Diagnose und OTA-Fähigkeit

   SOVD ermöglicht die Kommunikation über IP-basierte Netzwerke. Dadurch sind Diagnose und Fahrzeugwartung auch aus der Ferne möglich – ein entscheidender Vorteil für Connected Services, Flottenmanagement und Over-the-Air Updates.

4. Live-Daten und Ereignis-Benachrichtigungen

   Neben klassischen Anfragen unterstützt SOVD auch das Subscription-Modell: Clients können sich auf bestimmte Fahrzeugzustände abonnieren und bei Änderungen aktiv benachrichtigt werden.

5. Security by Design

   SOVD bietet integrierte Sicherheitsmechanismen wie Authentifizierung, Verschlüsselung (TLS) und rollenbasierten Zugriff. So kann die Fahrzeugdiagnose gezielt abgesichert werden.

6. Kompatibilität mit modernen Entwicklungsprozessen

   Durch die Nutzung offener Schnittstellen kann SOVD leicht in DevOps-Prozesse, CI/CD-Pipelines und Cloud-Umgebungen eingebunden werden.

Anwendungsbeispiele:

• Werkstattdiagnose

  Intuitive Web-UIs greifen direkt per WLAN oder Ethernet auf das Fahrzeug zu.

• Remote Services

  Ein Backend-System liest Fahrzeugdaten aus und erstellt proaktiv Service-Tickets.

• Flottenmanagement

  Echtzeitdaten aus der Fahrzeugflotte werden aggregiert und ausgewertet.

OTX SOVD-Extension

In der ASAM-Arbeitsgruppe „OTX-Extensions“ wurde Mitte 2025 OTX um eine SOVD und eine JSON-Extension erweitert. Die JSON-Extension ermöglicht das Lesen, Interpretieren und Schreiben von JSON-Daten und ist Grundlage der SOVD-Extension. Die SOVD-Extension arbeitet als SOVD-Client und stellt neue Datentypen, Actions und Terms für den Zugriff auf einen SOVD-Server bereit, siehe Abbildung 3. Die SOVD-Extension unterstützt die Version 1.0 von ASAM SOVD sowie die ISO/DIS 17978-3. Sie wird zukünftig für neue SOVD-Versionen erweitert.

Abbildung 3: SOVD-Architektur mit OTX

Die SOVD-Extension ermöglicht das Browsen der SOVD-Entitäten und den Zugriff auf die Ressourcen. Die Ressourcen repräsentieren die Diagnosefähigkeiten der Entitäten. Es werden Funktionen bereitgestellt, um die Diagnosefähigkeiten jeder Ressource abzurufen und um Diagnoseoperationen zu konfigurieren oder auszuführen. Die SOVD-Entität „Function“ wird derzeit von der SOVD ODX-Extension nicht unterstützt.

Das nachfolgende Beispiel in OTL-Code zeigt die Anwendung der SOVD-Extension. Es sollen exemplarisch alle gefundenen Fehler der Komponenten der ersten Ebene ermittelt und als Liste zurückgegeben werden.

// Returns all faults found
public procedure GetFaults(out List<SOVD.FaultDescriptor> faultLst)
{
   // Local variables
   List<SOVD.EntityDescriptor> servers;
   SOVD.EntityDescriptor server;
   Map<String, SOVD.EntityDescriptor> components;
   SOVD.EntityDescriptor component;
   Map<String, SOVD.FaultDescriptor> faults;
   SOVD.FaultDescriptor fault;

   // Gets the discovered SOVD servers
   servers = SOVD.GetDiscoveredSovdServer();

   // Browse through all discovered servers
   foreach(server in servers)
   {
      // Gets all components of a certain server
      components = SOVD.GetComponentDescriptors(server);
      // Browse through all components
      foreach(component in components)
      {
         // Gets all faults of a certain component
         faults = SOVD.GetFaultsAsDescriptors(component);
         // Browse through all faults   
         foreach(fault in faults)
         {
            // Add the faults to the list which will be returned
            ListAppendItems(faultLst, { fault });
         }
      }
   }
}

OTX und SOVD - Eine starke Kombination

Ein besonders starker Anwendungsfall entsteht durch die Verbindung von SOVD mit OTX. Mit OTX lassen sich standardisierte Diagnosesequenzen spezifizieren, implementieren, testen und in beliebigen Umgebungen austauschen und ausführen. Durch die neue SOVD-Extension für OTX können Webservice-basierte Diagnosedaten nahtlos in OTX-Sequenzen integriert werden. Für die Kombination von OTX und SOVD sind prinzipiell zwei Anwendungsszenarien möglich, siehe Abbildung 4.

Im Szenario A verwendet SOVD den OTX-Standard. Der SOVD-Server startet OTX-Prozeduren in der OTX-Runtime. Hierfür bietet sich die SOVD-Entität „Function“ an. Sie stellt eine allgemeine, funktionale Schnittstelle für beliebige, herstellerspezifische Diagnosefunktionen bereit. Ein SOVD-Client im Backend könnte somit über die SOVD-Function eine beliebige OTX-Prozedur starten.

Abbildung 4: Anwendungsszenarien OTX und SOVD

Im Szenario B arbeitet die OTX-Runtime selbst als SOVD-Client. Über die neue SOVD-Extension können aus OTX praktisch beliebige SOVD-Funktionen verarbeitet werden. Zusätzlich kann die OTX-Runtime Diagnosekommunikation auch wie bisher über die DiagCom-Extension durchführen und eignet sich daher sehr gut für Migrationsszenarien oder einen Misch-Verbau mit Steuergeräten, die nicht über SOVD verfügbar sind.

In der Praxis ist eine Kombination von Szenario A + B für den so genannten OnBoard-Tester wahrscheinlich, siehe auch Abbildung 5. Über einen SOVD-Client werden OTX-Prozeduren an der OTX-Runtime gestartet, die über die SOVD-Extension von OTX selbst als SOVD-Client agieren und Funktion des SOVD-Servers verwenden können. Dieses Szenario kombiniert die Vorteile aus beiden Welten am besten.

Vorteile der Kombination von OTX und SOVD:

1. Moderne Kommunikation trifft strukturierte Logik

   SOVD liefert die IP-basierte, serviceorientierte Schnittstelle zum Fahrzeug und OTX modelliert die Diagnoselogik standardisiert und visuell.

2. Wiederverwendbare Diagnoseabläufe

   Mit OTX lassen sich Diagnoseabläufe spezifizieren, implementieren, testen, freigeben, austauschen und in beliebigen Zielsystemen anwenden. SOVD ermöglicht die dynamische Ausführung dieser Abläufe über Webservices – lokal oder remote.

3. Unabhängigkeit von Protokollen und Plattformen

   OTX bleibt gleich – egal ob die Kommunikation über MVCI, SOVD, UDS oder DoIP im Backend stattfindet. Die Runtime abstrahiert den Zugriff über die gewählte Kommunikationsschicht.

4. Effiziente Remote- und Cloud-Diagnose

   OTX-Sequenzen können durch SOVD remote ausgeführt werden (z. B. über Cloud-Backend oder mobile Apps).

5. Transparenz und Debugging

   Durch die OTX-Laufzeitumgebung sind Diagnoseabläufe nachvollziehbar und testbar. Kombiniert mit SOVD lassen sich Logs, Events und Zustände gezielt auswerten.

6. Schnelle Integration in bestehende Systeme

   OTX kann in bestehenden Systemen leicht integriert werden. SOVD öffnet moderne Zugriffsmöglichkeiten ohne tiefgreifende Änderungen an der Logik.

7. Zukunftssicher für softwaredefinierte Fahrzeuge (SDV)

   SOVD ist konzipiert für zonale Architekturen und verteilte Systeme. OTX bildet eine stabile Schicht zur Modellierung – unabhängig von der Fahrzeugarchitektur.

Im folgenden Bild ist eine Beispiel-Architektur für die Kombination von OTX und SOVD im so genannten OnBoard-Tester dargestellt. Soll beispielsweise eine Fahrzeuganalyse durchgeführt werden, ruft ein Remote-SOVD-Client über den SOVD-Server eine entsprechende OTX-Prozedur als SOVD-Function auf. Die OTX-Runtime sammelt die Daten der gefundenen Steuergeräte über SOVD und zusätzlich direkt über UDS (DiagCom-Extension von OTX). Es erstellt das Protokoll und sendet es über den SOVD-Server zurück an den Remote-SOVD-Client.

Abbildung 5: SOVD / OTX Beispiel-Architektur (OnBoard-Tester)

Toolunterstützung

Die SOVD- und JSON-Extensions werden ab der Version 9 der OTX-Toolkette komplett unterstützt. Eine Offline-Capability-Description des Anwenders im JSON-Format kann geladen und in der Toolbox dargestellt werden. Anmerkung: die Offline-Capability-Description beschreibt die für den Anwender verfügbaren Daten des SOVD-Servers.

Abbildung 6: OTX IDE Open Test Framework mit SOVD-Unterstützung

Darauf aufbauend kann der Anwender seine OTX-Prüflogik programmieren. Checker-Regeln prüfen die Korrektheit der Eingaben und eine eingebaute SOVD-Server Simulation erlaubt es, den OTX-Ablauf auch ohne verfügbaren Server zu testen.

Fazit

SOVD ist mehr als eine neue Diagnoseschnittstelle – es ist ein Paradigmenwechsel in der Fahrzeugdiagnose. Waren die Diagnosesysteme der Vergangenheit dem Mangel geschuldet, schafft der Ansatz, Diagnosefunktionen als Webservices bereitzustellen, neue Möglichkeiten für Effizienz, Integration und Innovation.

Die Kombination von OTX und SOVD verbindet standardisierte Diagnoselogik mit moderner, serviceorientierter Fahrzeugkommunikation. OTX ermöglicht die strukturierte und wiederverwendbare Modellierung von Diagnoseabläufen, während SOVD als IP-basierte Schnittstelle einen flexiblen, sicheren und remotefähigen Zugriff auf Fahrzeugdaten bietet. Gemeinsam ermöglichen sie eine effiziente, prozesssichere Entwicklung, Ausführung und Automatisierung von Diagnoseprozessen – lokal in der Werkstatt, im Prüffeld oder remote über die Cloud. OTX und SOVD sind eine zukunftssichere Kombination im Kontext softwaredefinierter Fahrzeuge und modularer Fahrzeugarchitekturen.