SOVD – Service-Oriented Vehicle Diagnostics
Der neue SOVD-Standard ist ein moderner Ansatz zur Fahrzeugdiagnose, bei dem Diagnosedaten und -funktionen als digitale Dienste bereitgestellt werden.
Er löst klassische Diagnoselösungen, basierend auf ISO-Standards wie z. B. UDS (14229) oder MCD (ISO 22900-3), ab und stellt umfangreiche Diagnosemöglichkeiten mithilfe moderner WEB-Standards im Fahrzeug zur Verfügung, die in der ISO 17978 spezifiziert sind.
Diese Schnittstelle ermöglicht einen flexiblen Zugriff und eine einfachere Integration in Backends, Cloud-Systeme und die Nutzung moderner Technologien wie Big Data, IoT oder KI.
Motivation
Die Entwicklung von SDVs (Software-Defined Vehicle) wird insbesondere durch die Einführung von EVs (Elektrofahrzeuge) und der Möglichkeit, in aktuellen Fahrzeugen auch APPs in den Fahrzeugen zu installieren, vorangetrieben und stellt neue Anforderungen an die Diagnose von Fahrzeugen. In Zukunft müssen neben den klassischen Steuergeräten (ECUs) auch APPs und als Software realisierte Fahrzeugfunktionalitäten diagnostiziert werden.
Da es zumindest in den nächsten Jahren noch einen Mischverbau von bisheriger und neuer Technik geben wird, stellt SOVD ein standardisiertes API zur Verfügung, welches alle Use-Cases abdeckt.
Die mit EVs und SDVs einhergehende Einführung von HPCs (High Performance Computern) im Fahrzeug bietet erstmals die Möglichkeit, komplette Diagnoseumfänge in das Fahrzeug zu verlagern und über das SOVD API zur Verfügung zu stellen.
Entwicklung des Standards bei ASAM/ISO
Die ASAM SOVD Spezifikation definiert einen Standard, der alle Aufgaben der Fahrzeugdiagnose unter Berücksichtigung der aktuellen Herausforderungen abdeckt. Dabei geht es im Wesentlichen um den normierten Zugriff auf die im Fahrzeug befindlichen SOVD-Server. Herkömmliche ECUs werden durch die Verwendung des im SOVD-Standard vorgesehenen CDAs (Classic Diagnostic Adapter) abgedeckt.
- SOVD wird seit 2019 bei ASAM e.V. als Standard entwickelt
- SOVD wurde als ASAM Version 1.0 bei der ISO als NWIP eingereicht und als neuer ISO Standard angenommen
- SOVD wurde als ASAM Version 1.1 Ende 2024 an die ISO übergeben und wird dort als ISO 17978 den üblichen Prozess durchlaufen und veröffentlicht werden.
Experten der ACTIA IME GmbH waren über eine Arbeitsgruppe des ASAM e.V. (Association for Standardization of Automation and Measuring Systems) an der Entwicklung und Gestaltung des SOVD-Standards beteiligt und sind weiterhin aktive Mitglieder in den Arbeitsgruppen.
SOVD – Technische Details
Key-Features von SOVD
Entity-Konzept
Sämtliche im Fahrzeug vorhandenen Diagnoseendpunkte werden über das Entity-Konzept im SOVD-Standard abgebildet.
Entities sind:
- der SOVD-Server selbst,
- Komponenten (vergleichbar mit klassischen ECUs)
- APPs (Softwarekomponenten jeglicher Art)
- Areas (gruppierte Bereiche, z. B. früher der PowerTrain)
- Functions (funktional zusammenhängende Entities -> Anfragen, die mehrere Entities adressieren, z. B. Vehicle-Health)
Ressourcen-Konzept
- Data Read/Write
- Fault Handling
- Configuration
- Operations
- Handling of Bulk Data
- Restart
- Support of Target Modes
- Software Update
- Clearing Data
- Locking
- Cyclic Subscriptions
- Triggers
- Script Execution
- Logging
Capability-Description
Die in einem SOVD-Server vorhandenen Diagnosefunktionalitäten werden über die Capability-Description bereitgestellt. Diese gibt es in zwei zentralen Ausprägungen:
- Offline Capability Description:
Diese beinhaltet die vollumfängliche Diagnosebeschreibung einer Fahrzeugklasse inklusive aller Varianten und Verbauoptionen und stellt sie einem Diagnoseautor zur Verfügung. - Online Capability Description:
Diese beinhaltet genau die zu der exakten Fahrzeugvariante inkl. der dort aktiven Softwareversionen und -Konfigurationen möglichen Diagnosedatenbeschreibungen.
D.h., der SOVD-Server im Fahrzeug kennt genau dessen Zustand und bietet die passende Diagnose an. Damit entfällt das früher übliche und notwendige, aufwendige Variantenhandling.
Diese Description ist im Standard als „optional“ gekennzeichnet und kann speziell und exakt auf die Ressource/Entity angefragt werden. - Optional kann bei Anfragen an eine Ressource das zugrundeliegende Schema angefordert werden. Dieses Schema beschreibt den exakten Aufbau der zurückgelieferten Ressource.
Modernes REST/JSON basiertes API
Gegenüber der klassischen Diagnose, wo Diagnoseanfragen umfangreich aufgebaut und parametrisiert werden mussten und auch die Diagnoseantworten mit viel Aufwand ausgewertet wurden, wird das SOVD API über moderne WEB-Techniken bereitgestellt.
Eine Diagnoseanfrage wird per REST-Request an den SOVD-Server gestellt, ein einfacher GET-REST-Request ist vergleichbar mit dem Aufruf einer URL in einem Browser (z. B. http://sovd.actia.de/v1.0/components). Der ACTIA SOVD Demo Server würde in diesem Fall die Liste der verfügbaren Komponenten-Entities zurückliefern. Die Beschreibung der REST-Requests erfolgt über OPEN-API, einem aus Swagger hervorgegangenen Standard zur Beschreibung von APIs. In REST und damit auch in SOVD ist es möglich, die Aufrufe als GET (Informationen holen), PUT/POST (Informationen senden) und DELETE (Informationen löschen) auszuführen.
Die Antwort des SOVD-Servers erfolgt im JSON-Format, welches sowohl von SOVD-Clients als auch jedem handelsüblichen Browser verarbeitet werden kann.
Discovery
SOVD-Server beinhalten die Möglichkeit, ihr Vorhandensein in einem Netzwerk dynamisch ermitteln zu können. D.h. ein Diagnoseclient kann über mDNS (Multicast-DNS) herausfinden, ob ein oder mehrere SOVD-Server vorhanden und wie diese zu erreichen sind.
Software-Update
Der SOVD-Standard bietet unabhängig von einer konkreten Entity das Software-Update an. Dadurch ist es möglich, sowohl einzelne Komponenten (früher ECUs), mehrere Entities (also Komponenten, APPs, ….) oder gar ein komplettes Fahrzeug auf einmal mit einem neuen Softwarestand zu versehen. Dazu werden die notwendigen Softwarepakete beim SOVD Server registriert und danach dann gestartet. Über die Statusabfrage kann der aktuelle Status und damit auch die Fertigstellung eines Softwareupdates ermittelt werden.
Use Cases
Das klingt alles sehr einfach und technisch zwar machbar, es wird aber sicherlich nicht möglich sein, dass man sich mit einem Diagnoseclient neben ein Fahrzeug stellt und Diagnose durchführen kann. Es gibt geordnete Zugangsszenarien, um Zugang zum Fahrzeugnetzwerk zu bekommen und hier wird zwischen mehreren Use-Cases unterschieden:
- In-Vehicle
Hier kann z. B. eine APP oder Softwarefunktion innerhalb des Fahrzeugs auf Diagnoseinformationen zurückgreifen oder Aktionen über die Diagnose auslösen. Das hat den enormen Vorteil, dass die Information nur genau einmal durch den SOVD-Server angefragt und aufbereitet werden muss. Früher haben die ECUs die Botschaften auf dem Bussystem mitgehört bzw. angefragt und mussten Parametrierung und Aufbereitung der Daten (z. B. in die richtige Einheit) jeweils selbst implementieren. - Remote
Die Diagnose wird über eine Remote-Verbindung (Backend) durchgeführt. - Co-Located
Dieser Use-Case deckt den Werkstattfall ab und wird angewendet, wenn eine Diagnosesitzung beaufsichtigt werden muss (z. B. wenn eine hydraulische Ansteuerung ausgeführt wird).
Der SOVD-Standard lässt bewusst offen, über welche Netzwerkkanäle die Kommunikation realisiert wird. Ein OEM kann dazu seine vorhandene Infrastruktur nutzen. Zusätzlich mit dem im SOVD-Standard vorgesehenem Authentifizierungskonzept bietet SOVD ein vollständiges Paket zur Steuerung des Zugriffes auf die Diagnose und eine rollenbasierte Bereitstellung von Diagnosefunktionalitäten.
SOVD – Service-Oriented Vehicle Diagnostics bei ACTIA
ACTIA entwickelt parallel zur Entstehung der Spezifikation beim ASAM einen eigenen SOVD-Server, der das Portfolio rund um die ISO-Diagnosestandards der Automobilindustrie bei ACTIA vervollständigt.
Der ACTIA SOVD-Server basiert auf einer Architektur, die es ermöglicht, den SOVD-Server sowohl mit einem schlanken UDS-Client als auch in verschiedenen Kombinationen bis hin zur vollständigen Integration eines D-Servers oder einer OTX-Runtime zu nutzen. Dazu wird der im SOVD-Standard vorgesehene CDA genutzt. Die ebenfalls bei ASAM im Rahmen der ISO 13209 entstehende SOVD-OTX-Extension wird in Zukunft Teil der OTX-Runtime sein und dieser wiederum den Zugriff auf das SOVD-API und damit z. B. APPs zu ermöglichen
Parallel dazu können APPs über das SOVD-API mithilfe flexibler Interfaces angesprochen werden. Bei APPs gibt es derzeit noch keine genormten Interfaces oder Diagnosefähigkeiten, d.h. hier lägt ACTIA durch das Konzept den Grundstein für die Integration kundenspezifischer APPs.
Das folgende Bild zeigt eine beispielhafte Integration eines vollständigen Diagnosestacks in den SOVD-Server.
Diese Integration erlaubt es, stabile, seit Jahren im Praxiseinsatz erprobte Diagnoseprotokolle nachzunutzen, gerade um spezielle Steuergeräte oder Protokolle, die es in den nächsten Jahren immer noch geben wird, parallel zu den modernen Architekturen, zu unterstützen. Außerdem sorgt eine weitestgehende automatische Datenkonvertierung z. B. von ODX zu einer SOVD-Capability für einen relativ schnelle Einsatz der neuen Technologie.
Auch wenn der SOVD-Server im Standard als InVehicle-Diagnose vorgesehen ist, wird ACTIA den SOVD-Server in Zukunft neben dem Einsatz in HPCs oder Telematikeinheiten ebenfalls in ihren VCIs anbieten, um eine einheitliche Diagnose auch und gerade in Übergangsszenarien zur Verfügung zu stellen.
