Integration statt Disruption

SOVD als Brücke zur SDV-Diagnose

SOVD verbindet klassische Diagnoseverfahren mit den Anforderungen HPC-basierter Fahrzeugarchitekturen. Der Standard schafft eine einheitliche Schnittstelle für Steuergeräte, Dienste und Softwarekomponenten und erleichtert so den Übergang zum SDV.

3 min
Warum wird SOVD zum Schlüssel der SDV-Diagnose? Der Standard verbindet UDS, HPCs und Services und senkt Risiken schon heute.
Warum wird SOVD zum Schlüssel der SDV-Diagnose? Der Standard verbindet UDS, HPCs und Services und senkt Risiken schon heute.

Software entwickelt sich zum entscheidenden Wettbewerbsfaktor heutiger Fahrzeuge. Kunden erwarten heute digitale Funktionen und regelmäßige Software-Updates. Das zeigt die Dynamik asiatischer Hersteller. Die Entwicklung muss den gesamten Lebenszyklus begleiten. Ziel ist das Software-Defined Vehicle (SDV), in dem Funktionen softwarebasiert und als Dienste realisiert werden. In der Praxis entstehen SDVs aber selten auf der grünen Wiese. Sie basieren auf vorhandenen oder zugekauften Systemen. Hohe Kosten der Neuentwicklung stehen einer geringen Wirtschaftlichkeit gegenüber. Wettbewerbsvorteile entstehen vor allem durch Funktionen wie Infotainment, Fahrerassistenzsysteme oder digitale Dienste.

Diagnose als Integrationsaufgabe

Für die Diagnose bedeutet das, dass bewährte Strategien zur Lokalisierung von Fehlern in Komponenten, deren Vernetzung sowie Wechselwirkungen bei Softwarefehlern nur noch bedingt greifen. Moderne Fahrzeugarchitekturen erfordern also erweiterte Diagnoseansätze.

Herkömmliche und neue Diagnoseverfahren müssen sich in etablierte Prozesse über den gesamten Fahrzeuglebenszyklus integrieren. Etablierte Diagnosemechanismen fallen dabei nicht weg, sondern müssen nahtlos mit den neuen Möglichkeiten zur Diagnose softwarebasierter Funktionen zusammengeführt werden.

SDV-Diagnose: Klassische Protokolle greifen zu kurz

Die Steuergerätesoftware wurde lange als weitgehend fehlerfrei betrachtet. Diagnoseprotokolle wie UDS fokussieren auf Sensoren, Aktoren und deren Vernetzung. Messwerte und Fehlerspeichereinträge lassen sich damit zuverlässig erfassen. Für HPC-basierte Fahrzeugarchitekturen mit neuen Anforderungen an die Diagnose reicht das jedoch nicht mehr aus.

Funktionen werden im SDV zunehmend durch das Zusammenspiel mehrerer Dienste realisiert, die auf unterschiedlichen Systemen laufen und zusätzlich Informationen aus der Cloud integrieren. Treten Fehler auf, genügt es nicht mehr, einzelne Komponenten isoliert zu betrachten. Die Diagnose muss vielmehr Abhängigkeiten zwischen Diensten und deren Ausführungskontext erfassen, um die Fehlerursache identifizieren zu können.

Softwarefehler lassen sich häufig nicht mehr einem einzelnen Dienst zuordnen. Sie entstehen durch Wechselwirkungen zwischen mehreren Diensten, Ressourcenengpässen und unerwartetem Laufzeitverhalten. Die Ursache liegt zeitlich oft vor dem erkannten Fehler. Erforderlich sind daher Monitoring und die Korrelation von Ereignissen, vergleichbar zur Diagnose von verteilten Diensten in Cloud-Infrastrukturen.

Viele dieser Fehler treten erst nach Software-Updates im Feld auf. Diagnose wird damit zu einer wesentlichen Voraussetzung für den Erfolg des SDV. Nur wenn Fehler nach der Auslieferung schnell erkannt und analysiert werden, lässt sich das Versprechen kontinuierlicher Weiterentwicklung einlösen. Das SDV droht sonst zum Werkstattfall zu werden. Klassische Diagnose- und Reparaturprozesse sind auf Softwarefehler aber nur unzureichend vorbereitet.

Als Diagnoseschnittstelle ist SOVD nicht auf eine bestimmte Fahrzeugarchitektur festgelegt. Der Standard unterstützt klassische E/E-Architekturen ebenso wie Domänen- und Zonenarchitekturen auf HPC.
Bild 1: Als Diagnoseschnittstelle ist SOVD nicht auf eine bestimmte Fahrzeugarchitektur festgelegt. Der Standard unterstützt klassische E/E-Architekturen ebenso wie Domänen- und Zonenarchitekturen auf HPC.

SOVD verbindet bestehende und neue Diagnosewelten

Klassische Steuergeräte bleiben auf absehbare Zeit Bestandteil von Fahrzeugen. SOVD (ISO 17978) unterstützt die Diagnose der Steuergeräte und HPC-basierten SDVs über eine gemeinsame Schnittstelle. Hierbei werden nicht nur die Diagnosefähigkeiten von UDS unterstützt, sondern auch die für HPCs und service-orientierte Architekturen erforderlichen Funktionen: Der Zugriff auf Log-Dateien, die Remote-Diagnose oder die temporäre Integration neuer Diagnosefunktionen.

Als Diagnoseschnittstelle ist SOVD nicht auf eine bestimmte Fahrzeugarchitektur festgelegt. Der Standard unterstützt klassische E/E-Architekturen ebenso wie Domänen- und Zonenarchitekturen auf HPCs (Bild 1). Unterhalb der SOVD-Schnittstelle sorgen Adapter für die einheitliche Diagnose sowohl klassischer Steuergeräte über UDS oder J1939 als auch von Betriebssystemen und Diensten eines HPC.

SOVD entkoppelt Diagnosewerkzeuge von der zugrunde liegenden E/E-Architektur, den verwendeten Diagnoseprotokollen und einzelnen Steuergeräten. Für Diagnosewerkzeuge entsteht eine einheitliche Sicht auf Fahrzeug, Funktionen und Softwarekomponenten – unabhängig davon, aus welcher Quelle die Informationen stammen. Die Komplexität bestehender Diagnoseprotokolle bleibt erhalten und wird hinter der standardisierten SOVD-Schnittstelle gekapselt.

SOVD liefert Mehrwerte auch ohne SDV

SOVD bietet bereits in aktuellen Fahrzeugen Mehrwert. Wird SOVD erst bei künftigen SDVs eingesetzt, bleibt erhebliches Potenzial ungenutzt, denn es kann bereits heute auf vorhandenen Infotainment- oder Telematik-Steuergeräten realisiert werden (Bild 2).

Hierbei geht der Nutzen von SOVD über die Diagnose von HPCs hinaus. Diagnose wird zu einer integrierten Fahrzeugfunktion, die über Engineering, Produktion und Aftersales hinweg genutzt werden kann. In der Produktion stehen Diagnosefunktionen direkt im Fahrzeug bereit. Externe Tester werden weitgehend überflüssig, Fertigungsbereiche lassen sich für Diagnoseaufgaben nutzen. Serienprojekte haben die Praxistauglichkeit dieses Ansatzes bestätigt.

Der Weg zur SDV-Diagnose beginnt heute

Bild 2: Android-Infotainment als Ausführungsumgebung für SOVD.
Bild 2: Android-Infotainment als Ausführungsumgebung für SOVD.

Die Einführung von SOVD verändert Prozesse und Werkzeuge. Erfolgt sie erst im ersten SDV-Programm, überlagern sich Diagnosestrategie, Architektur- und Prozessänderungen mit entsprechend höheren Risiken.

SOVD ist nicht auf SDVs beschränkt. Durch die Unterstützung bestehender Diagnoseprotokolle kann es schon heute in Fahrzeugen oder über externe Komponenten wie VCI oder Laptop realisiert werden. Die schrittweise Einführung in einer bekannten Umgebung führt zu kontrolliertem Lernen: Auswirkungen auf Prozesse und Werkzeuge werden früh sichtbar, geeignete Maßnahmen können abgeleitet und erste Diagnosekonzepte für HPCs erprobt werden. Dies reduziert Risiken, bevor SOVD im SDV produktiv eingesetzt wird.

Integration schlägt Disruption

SDVs werden auf absehbare Zeit einer hybriden E/E-Architektur folgen: HPCs übernehmen Funktionen wie Infotainment oder automatisiertes Fahren, während klassische Steuergeräte weiterhin Komfort- und Sicherheitsfunktionen realisieren.

SOVD übernimmt die Rolle des Integrators. Der Standard schafft eine gemeinsame Diagnoseschnittstelle und ermöglicht die schrittweise Transformation bestehender Systeme. Damit wird der Übergang zum Software-Defined Vehicle zur Evolution statt zur Disruption. (na)

Autor:

Dr. Boris Böhlen, Senior Manager Sales und SOVD Standardisation Expert bei DSA