Seitennavigation
- Zum Anfang der Seite
SOVD - Service-Oriented Vehicle Diagnostics
Mit dem Einzug von HPCs (High-Performance Computer) und damit verstärkt Software basierten Systemen in zukünftige Fahrzeuge ergeben sich auch für die Diagnose neue Herausforderungen. Der Einzug von leistungsfähigen Rechnern mit heterogenen Betriebssystemen und einer Vielzahl von parallelen Prozessen erfordert neue Features der Diagnose.
Die deutlich höhere Frequenz, mit welcher sich die Software und damit auch der Diagnoseumfang des Fahrzeugs ändert, erfordert auch neue Ansätze bei der Datenhaltung.
Vor diesem Hintergrund wurde 2019 im ASAM das Projekt „Service Oriented Vehicle Diagnostics“ (SOVD) gestartet. Die Standardisierung hat zum Ziel, eine moderne, einfache Diagnoseschnittstelle zu schaffen, welche gleichermaßen den Zugriff auf klassische Steuergeräte und aufkommende Software-basierte Systeme ermöglicht. Zielsetzung ist außerdem einen einheitlichen Zugriff für die Szenarien Remote, Proximity und in-Vehicle Diagnose zu ermöglichen.
Vector ist dabei im ASAM federführend und treibt die SOVD-Standardisierung voran, um für diese Herausforderungen passende sowie ganzheitliche Diagnoselösungen zu bieten.
Herausforderungen
Mit dem Einzug von HPCs und damit verstärkt Software basierten Systemen im Auto ergeben sich auch für die Diagnose neue Herausforderungen.
Daten, welche zur Diagnose von HPCs und Apps benötigt werden, lassen sich schlecht mit der statischen Struktur von ODX (Open Diagnostic eXchange format) und UDS (Unified Diagnostic Service) vereinbaren. Auch nutzen native Apps andere Schnittstellen bzw. Datenformate, welche sich nur schwer in eine UDS basierte Byte-Folge abbilden lassen.
Eine Diagnose basierend auf UDS erfordert eine passende statische Offline-Beschreibung zur Kommunikation (typischerweise im ODX-Format). Die wesentliche Zielsetzung einer verstärkt Software-basierten Architektur ist es jedoch deutlich schneller und flexibler neue Software und damit Funktionalität ins Auto zu bringen. Hier wird es in der Praxis kaum gelingen, dass für jede Software-Variante immer die passsende Diagnosebeschreibung verfügbar ist.
Die Adressierung der heutigen Diagnose basiert auf statischen Identifiern und ist damit wenig flexibel. Änderungen an der Kommunikationsmatrix sind komplex und werden daher nur selten durchgeführt. Dies steht ebenfalls im Gegensatz zum Wunsch schnell neue Software-Anteile ins Fahrzeug zu bringen.
Auch nach der Einführung von Zentralrechnern im Fahrzeug wird es weiterhin eine erhebliche Anzahl klassischer Steuergeräte geben, welche die Basis für der SW-basierten Funktionen bilden. Diese klassischen Steuergeräte werden aktuell und auch in Zukunft aufgrund Ihrer Anforderungen und Ressourcen auf bekannten SW-Plattformen (bspw. AUTOSAR Classic) basieren. Sie werden eine UDS-basierte Diagnose zur Verfügung stellen. Es gilt auch diese Diagnose nahtlos in SOVD zu integrieren.
Ziele
- Eine API (Application Programming Interface) für die Diagnose und das Software-Update (fahrzeugübergreifend)
- Ein konsistentes API, das sowohl für neue Systeme als auch für traditionelle Sensor- / Aktor-Systeme genutzt werden kann.
- Einsatzszenarien: proximal (verdrahtet mit dem Auto oder per Nahbereichskommunikation), in-vehicle (mitfahrend im Auto) und remote (aus der Ferne mit dem Auto)
- Ein selbstbeschreibendes API, das – anders als heute - auch eine Diagnose ohne eine externe Beschreibungsdatei ermöglicht. Trotzdem wird man auch künftig irgendeine externe Beschreibung benötigen, um beispielsweise variantenübergreifende Prüfabläufe erstellen zu können.
- Es sollen geeignete bestehende Technologien ausgewählt und kombiniert werden. Es ist ein ausdrückliches Vermeidungsziel eine neue Technologie zu erfinden.
Anwendungsfälle
Innerhalb des Fahrzeugs tragen verschiedenste Softwareanteile und Geräte mit Prozessoren und Controllern zur Funktion und auch zur ganzheitlichen Diagnose bei. Anfragen zu Diagnose und Software-Update werden jeweils an den passenden Bearbeiter weitergeleitet.
Abstrakt formuliert handelt es sich bei Diagnose-Anfragen um Operationen auf einer konkreten Ressource, z.B.
- Lesen von Messwerten und Systemkenngrößen, einzeln oder als Messwertreihe
- Auslesen von Ereignis- und Fehlerspeichern
- Ändern von Parametern
- Starten von speziellen Diagnose-Funktionen
- Eingriff in die normale Steuerungsfunktion von Aktoren und Sensoren
Hinzu kommen jetzt Anfragen, um die Selbstbeschreibung („Capability Description“) einer konkreten Ressource (Hardware oder Software-Teil) abzurufen. Der verfügbare Diagnoseumfang hängt ggf. von der Rolle bzw. der Berechtigung des Anfragenden ab. Die Selbstbeschreibung umfasst alle Diagnoseumfänge, die von der aktuellen Rolle angefragt werden können.
Wird eine Anfrage an einen Hochleistungsrechner gerichtet, so wird die Anfrage direkt und dezentral von seiner Software bearbeitet, sozusagen nativ. Daher spricht man hier auch von nativer SOVD (native SOVD).
Wird eine Anfrage an ein Steuergerät gerichtet, das die UDS Diagnose unterstützt, so muss die SOVD Anfrage zunächst in die UDS Diagnose übersetzt werden und die Antwort entsprechend umgekehrt. Es erfolgt also eine Umsetzung von SOVD nach UDS, daher spricht man hier auch von dem klassischen Diagnose Adapter (Classic Diagnostic Adapter).
Für den Anfragenden sollte es keinen Unterschied machen, ob sich eine Anfrage an einen Hochleistungsrechner oder ein klassisches UDS Steuergerät richtet. Er verwendet die SOVD API und sieht ausschließlich symbolische Werte und Daten.
Standardisierung
Ziel von ASAM SOVD ist es, eine einheitliche API für neue Systeme und die traditionelle Sensor-/Aktor-Diagnose zu spezifizieren.
Eine wichtige Prämisse für die Entwicklung von ASAM SOVD ist die Verwendung geeigneter Technologien, nicht aber die Neuerfindung einer neuen Technologie. Die SOVD API basiert auf einem http/REST-basierten Ansatz.
Die ASAM SOVD API unterstützt die Suche nach Inhalten, um die Notwendigkeit einer externen Datenspezifikation zu vermeiden. Dennoch gibt es Mechanismen für die Offline-Dokumentation und -Spezifikation, um Entwicklungs-, Produktions- und After-Sales-Prozesse bestmöglich zu unterstützen.
ASAM SOVD konzentriert sich auf die Definition der Schnittstelle (API). Die Implementierung von SOVD im Fahrzeug ist nicht Gegenstand des ASAM-Projekts. Es gibt aber bereits Aktivitäten in AUTOSAR, um die Implementierungsthematik zu behandeln.
Ins Gespräch kommen
Sie wollen die nächste Generation der Diagnose aktiv gestalten? Dann lassen Sie uns miteinander reden!
Tobias Weidmann
ASAM SOVD Projektleiter - Let’s build SOVD solutions!
Wissenswert
Diagnostics beyond UDS
[B. Gottschalk (Mercedes-Benz AG), C. Rätz, (Vector)
Dieser Beitrag gibt einen Überblick über die Historie der Fahrzeugdiagnose sowie einen Ausblick auf aktuelle Entwicklungen und zukünftige Trends auf diesem Gebiet.
