Wofür steht die Abkürzung SOVD?

SOVD (Service-Oriented Vehicle Diagnostics) definiert eine Programmierschnittstelle (Application Programming Interface, API) für die Diagnose und Kommunikation mit software-definierten Fahrzeugen. Der Standard wird von der Standardization for Automotive Development "ASAM" definiert.

Der ASAM-Standard SOVD steht für Service-Oriented Vehicle Diagnostics (Serviceorientierte Fahrzeugdiagnose). SOVD definiert eine standardisierte Anwendungsprogrammierschnittstelle (Application Programming Interface, API) für die Diagnose und Kommunikation mit softwaredefinierten Fahrzeugen (Software-defined Vehicle, SDV).

Was ermöglicht der ASAM-Standard SOVD?

Bei SOVD (Service-Oriented Vehicle Diagnostics) handelt sich um einen flexiblen Standard, der einen einheitlichen Zugriff auf die Diagnoseinhalte von Hochleistungs-PCs (High Performance Computer, HPC) und den dazugehörigen Anwendungen sowie klassischen elektronischen Steuergeräten (Electronic Control Units, ECU) ermöglicht.

ASAM SOVD – Service-Oriented Vehicle Diagnostics

Diagnosestandard für softwaredefinierte Fahrzeuge (SDV)

Der Standard SOVD (Service-Oriented Vehicle Diagnostics) beschreibt eine Programmierschnittstelle (API) für ein im Fahrzeug integriertes Diagnosesystem. Dieses ermöglicht sowohl die Diagnose von Funktionen in High Performance Computern (HPC), wie sie in Software-definierten Fahrzeugen benötigt werden, als auch von heutigen ECUs. Dabei können verschiedene Anwendungsfälle adressiert werden: die klassische Diagnose am Fahrzeug, die Unterstützung über den Remote-Zugang, aber auch eine Diagnoseapplikation im Fahrzeug.

Anwender und Vorteile

Der Standard ist für alle Fahrzeughersteller sinnvoll einsetzbar, bei denen durch den zunehmenden Software-Anteil im Fahrzeug (Software-Defined Vehicle, SDV) und neue E/E-Architekturen die heutige Diagnose über UDS nicht mehr ausreichend Funktionalitäten anbietet. Die Remote-Fähigkeit ermöglicht damit erstmals einen standardisierten Fernzugriff auf Fahrzeuge.

Zu beachten ist, dass die Diagnose über SOVD nur mit Fahrzeugen oder über einen HPC möglich ist. Für Teilverbauungen und einzelne Steuergeräte muss daher in der Regel eine parallele Lösung eingesetzt werden.

SOVD – Service-Oriented Vehicle Diagnostics

Use Cases

Der SOVD-Standard definiert eine API für ein Diagnosesystem, das in einem HPC im Fahrzeug implementiert ist. Dies ermöglicht Anwendungsfälle am Fahrzeug (Proximity) aus der Ferne (Remote) oder im Fahrzeug (InVehicle)

Proximity
In diesem Fall befindet sich der Diagnoseanwender nahe am Fahrzeug und greift mit seiner Anwendung über eine Drahtlosverbindung oder auch ein Kabel auf das Diagnosesystem im Fahrzeug zu.
Typischer Anwendungsfall ist die Werkstatt, in der mithilfe der Diagnose der Reparaturvorschlag ermittelt wird.

Remote
Im Remote-Fall wird über das Internet und entsprechende Funktechnologien, beispielsweise 4G, auf das Diagnosesystem im Fahrzeug zugegriffen. Anwendungsbeispiele sind die Fernunterstützung in der Werkstatt, die Flottendiagnose im Fahrversuch oder Predictive Maintenaince Algorithmen für Serienfahrzeuge.

InVehicle
Hier ist die Diagnoseanwendung lokal im Fahrzeug verortet und hat so direkten Zugriff auf das Diagnosesystem. Ein Beispiel ist eine SOTA-Anwendung (Software Over The Air), bei der die Anwendung regelmäßig in der Cloud auf neue Software prüft, diese bei Bedarf herunterlädt und dann den Steuergeräte-Update durchführt.

Voraussetzungen

Neben der Unterstützung obiger Use Cases hat sich die SOVD Standardisierung zum Ziel gesetzt, Besonderheiten von HPCs in die Diagnose zu integrieren. Dazu gehört insbesondere, dass HPCs grundsätzlich als Mehrkernsystem auch mit unterschiedlichen Betriebssystemen auf einem Gerät ausgeführt sein können. Diese Architektur sowie die Integration mehrerer Fahrfunktionen auf einem Gerät sind ebenfalls einer Diagnose zu unterziehen - also einer Geräte-Diagnose.

Ziel der Standardisierung war es, weitgehend eine Serviceorientierte Architektur (SOA) umzusetzen. Das bedeutet, dass ein SOVD-System (Server) von einer Anwendung (Client) nach einem Satz von Informationen angefragt wird, es für die Anwendung aber nicht wichtig ist, wie diese Informationen im System generiert wird. Zur Umsetzung sollten in der Standardisierung ausdrücklich nur auf existierende Technologien zurückgegriffen werden.

SOVD Kommunikation | SOVD Client und Fahrzeug

Sie haben Fragen zu unseren Lösungen oder benötigen Unterstützung?

Kommen Sie auf uns zu. Wir freuen uns über Ihr Interesse!

Kontaktieren Sie uns!

Umsetzung

Der Standard verlangt eine Instanz eines SOVD-Servers auf einem HPC im Fahrzeug. Dieser wird über eine eindeutige URI (Unified Ressource Identifier) angesprochen und stellt ein definiertes API zur Verfügung. Die Parametrierung der API-Methoden erfolgt über JSON-Strings oder direkt über die URL.
Ein SOVD-Server kann verschiedene Anwendungen implementieren (Entities):

Components sind Steuergeräte im Fahrzeug oder Software-Module, die Fahrfunktionen implementieren und direkt angesprochen werden können
Classic Diagnostic Adapter (CDA) - ist eine Sonderform einer Component und ermöglicht Diagnose mit heutigen Steuergeräten über UDS
APP - Anwendungen für übergreifende Diagnoseabläufe, auf die über SOVD-Dienste zugegriffen werden kann
FUNC - Zugriff auf Diagnosemethoden, die mehrere Informationsquellen zusammenführen
AREA - Zugriff auf Informationen aus bestimmten Bereichen einer E/E--Architektur im Fahrzeug, beispielsweise Zonen oder Domänen

Der Zugriff auf Elemente im Fahrzeug erfolgt streng hierarchisch. Es lassen sich jeweils für jedes Element einer Ebene die Diagnosefähigkeiten ermitteln. Unterhalb des SOVD-Servers werden die Entities angesprochen (Apps, Components/CDA, FUNC, Area), darunter jeweils für Diagnose relevanten Ressourcen. Beispiele für Resourcen sind Fehler (faults), Messwerte (data) oder Kodierungen bzw. Parametrierungen (configurations). Für jeden Diagnoseaufruf ergibt sich damit jeweils ein Zugriffspfad

Log-Dateien und damit wichtige Elemente für die Diagnose innerhalb des HPCs sind ebenfalls eigene Ressourcen.

Die Implementierung eines SOVD-Servers wird durch die Standardisierung nicht adressiert. Eine reale Implementierung wird in der Regel aber eine Parametrierungsmöglichkeit besitzen, um einerseits Verbauvarianten zu unterstützen, andererseits aber auch Änderungen der Diagnosefunktionalität während der Fahrzeuglebenszeit zu erlauben.

Beispiel:

GET <serverurl>/components/ecm4711/data/RoundsPerMinute

GET <serverurl>/components/ecm4711/faults?Severity=2

Softing Erfahrung

Softing hat in der SOVD-Standardisierung von Anfang mitgearbeitet. Basierend auf den jahrelangen Erfahrungen mit Onboard-Diagnoselösungen sowie Remotesystemen auf Basis der Softing SDE eine Selbstverständlichkeit.