SOVD und das Reparaturrecht der EU: Aufbau einer skalierbaren und konformen diagnostischen Zugangsarchitektur für SDVs

Die meisten OEMs, die auf den EU-Märkten tätig sind, wissen bereits, dass das Reparaturrecht eingehalten wird. Die Gruppenfreistellungsverordnung für Kraftfahrzeuge (MVBER) schreibt seit 1995 unabhängigen Werkstätten den diskriminierungsfreien Zugang zu Diagnosegeräten vor. Dabei handelt es sich nicht um eine neue Verordnung, die sich auf die Branche auswirkt, sondern um eine etablierte Grundlage, die das Funktionieren der europäischen Automobilmärkte drei Jahrzehnte lang geprägt hat.

Was sich geändert hat, ist das Fahrzeug. Softwaredefinierte Fahrzeuge — mit zentralisierten HPCs, containerisierten Anwendungen, OTA-Updates aus der Ferne und mit der Cloud verbundenen Service-Workflows — machen traditionelle Diagnose-Architekturen immer spröder. Ansätze, die die MVBER-Anforderungen im Zeitalter der eigenständigen Steuergeräte und des Zugangs zu physischen Werkstätten technisch erfüllten, sind in der SDV-Ära nur schwer skalierbar.

Die eigentliche Frage für OEMs ist heute nicht, ob sie Diagnosezugang gewähren sollen — sie sind bereits dazu verpflichtet. Es geht darum, ob ihre Diagnosearchitektur diesen Zugriff tatsächlich auf eine Weise ermöglichen kann, die verwaltbar, sicher und betrieblich wertvoll ist, wenn die Komplexität der Fahrzeugsoftware zunimmt. SOVD ist die architektonische Antwort, und seine Vorteile gehen weit über die Einhaltung gesetzlicher Vorschriften hinaus und umfassen auch die Art und Weise, wie OEMs ihren Händlern und unabhängigen Servicenetzwerken die Arbeit an zunehmend softwaregesteuerten Fahrzeugen ermöglichen.

Die Compliance-Baseline: Was MVBER tatsächlich benötigt

Die MVBER gewährt OEMs eine Ausnahme von bestimmten wettbewerbsrechtlichen Anforderungen der EU — einschließlich des Rechts, Franchise-Händlernetze zu betreiben — als Gegenleistung für eine klare Verpflichtung: Unabhängige Werkstätten müssen diskriminierungsfreien Zugang zu technischen Daten, Diagnosetools und Reparaturinformationen zu fairen Handelsbedingungen erhalten.

Dies bedeutet, dass OEMs keine proprietären Diagnosearchitekturen verwenden können, um de facto Zugangsbarrieren zu schaffen, die autorisierte Händlernetzwerke gegenüber unabhängigen Werkstätten bevorzugen. Der Zugang muss technisch machbar und nicht nur theoretisch zulässig sein. Und da Fahrzeuge immer softwaredefinierter werden, wird die Anforderung „technisch machbar“ immer anspruchsvoller.

Eine konkrete Veranschaulichung: Ein großer OEM hat sich speziell mit SOVD befasst, weil seine firmeneigene Diagnoselösung in der derzeitigen Form in der EU nicht eingesetzt werden kann. Das Problem ist keine rechtliche Absicht, sondern die architektonische Realität. Proprietäre Systeme, die für Händlernetzwerke entwickelt wurden, erzeugen Zugriffsmuster, die nicht eindeutig dem diskriminierungsfreien Zugriff entsprechen, den MVBER benötigt, insbesondere wenn die Diagnose in Software- und Remotedomänen verlagert wird.

MVBER auf einen Blick

Aktiv seit 1995, verlängert bis 2028. Verlangt von den OEMs, unabhängigen Werkstätten Zugang zu Fahrzeugreparatur- und technischen Informationen zu diskriminierungsfreien Bedingungen zu gewähren, die mit denen vergleichbar sind, die Vertragshändlernetze erhalten. Gilt für alle OEMs, die Fahrzeuge auf den EU-Märkten verkaufen, unabhängig davon, wo der OEM seinen Hauptsitz hat.

Warum SDVs das Architekturproblem erschweren

Herkömmliche Diagnosen wurden auf der Grundlage einer stabilen, verteilten Steuergeräte-Architektur entwickelt. Jedes Steuergerät hatte feste Identifikatoren, statische Beschreibungsdateien und eine bekannte UDS-Implementierung. Konformität bedeutete, diese Schnittstellen zu veröffentlichen — komplex und unvollkommen, aber machbar.

Softwaredefinierte Fahrzeuge brechen dieses Modell auf verschiedene Weise:

• Dynamische Softwarekonfigurationen: Moderne SDVs führen containerisierte Anwendungen auf HPCs aus. Die Software ändert sich bei jedem OTA-Update. Das Fahrzeug, das ausgeliefert wurde, ist nicht das Fahrzeug, das sechs Monate später im Einsatz war. Statische Beschreibungsdateien und feste Steuergerätekennfelder können nicht Schritt halten.
  
• Remote- und cloudbasierte Service-Workflows: Die Diagnose erfolgt zunehmend, bevor das Fahrzeug eine Werkstatt erreicht — Vorabprüfung per Fernzugriff, Überwachung des Flottenzustands, OTA-ausgelöste Servicewarnungen. Herkömmliche Diagnosemodelle für den physischen Zugang waren dafür nicht konzipiert, und proprietäre Ferntunnel, die an ältere Systeme angeschraubt sind, sorgen für Fragmentierung.
  
• Zugangsvoraussetzungen für mehrere Interessengruppen: MVBER erfordert den Zugang für unabhängige Werkstätten. Flottenbetreiber benötigen ebenfalls ihren eigenen Zugang. Der zentrale OEM-Support benötigt Sichtbarkeit aus der Ferne. Die Techniker des Händlers benötigen Werkzeuge in der Werkstatt. Entwicklungsteams benötigen umfassenden Debug-Zugriff. All dies über proprietäre Punkt-zu-Punkt-Integrationen zu verwalten, ist nicht skalierbar.
  
• Prüf- und Compliance-Nachweise: Vorschriften wie UN R156 erfordern strukturierte Nachweise dafür, wie Softwareupdates verwaltet werden. Das Zusammenstellen von Compliance-Paketen aus verstreuten Protokollen auf proprietären Systemen wird angesichts des wachsenden Flottenvolumens zunehmend unhaltbar.

Das Ergebnis ist, dass OEMs, die für die vorherige Fahrzeuggeneration adäquate Diagnosearchitekturen entwickelt haben, gerade zu dem Zeitpunkt, zu dem ihre Service- und Compliance-Verpflichtungen erweitert werden, mit einer zunehmenden technischen Verschuldung konfrontiert sind.

SOVD: Die architektonische Grundlage für skalierbaren Zugriff

SOVD — Service-Oriented Vehicle Diagnostics — ist ein ASAM-Standard (der bis zur ISO 17978 weiterentwickelt wird), der eine HTTP/REST-basierte API für Fahrzeugdiagnosen definiert. Während bei herkömmlichen Diagnosen jedes Tool die Implementierung einer benutzerdefinierten Kommunikationslogik für jedes Fahrzeugprogramm voraussetzte, bietet SOVD einen gemeinsamen API-Vertrag. Diagnoseinhalte — Fehlercodes, Messungen, Konfigurationsparameter, Status der Softwareupdates — werden mithilfe von JSON über standardisierte REST-Endpunkte bereitgestellt, wobei die Funktionen über OpenAPI-Spezifikationen selbst beschrieben werden.

Für OEMs, die gleichzeitig die EU-Compliance-Verpflichtungen und die Komplexität der SDV-Services erfüllen, erfüllt SOVD beides mit derselben architektonischen Investition.

Eine Schnittstelle für alle Zugriffsszenarien

SOVD definiert eine einheitliche API, die für Remote- (Cloud-basiert), Proximity-Szenarien (in der Werkstatt) und fahrzeuginterne Szenarien funktioniert. Eine unabhängige Werkstatt, die in der Werkstatt eine Verbindung herstellt, ein Flottenbetreiber, der aus der Ferne überwacht, und ein OEM-Supporttechniker, der vor einem Servicebesuch eine Vorabprüfung durchführt, interagieren alle über dieselbe logische Schnittstelle — wobei der Zugriff durch rollenbasierte Berechtigungen geregelt wird, nicht durch den jeweiligen proprietären Toolstack.

Für die MVBER-Konformität ist dies wichtig, da die Architektur von Natur aus einen diskriminierungsfreien Zugang unterstützt. Der OEM definiert Autorisierungsstufen — wer sieht was —, aber die Schnittstelle selbst ist standardisiert und für jedes autorisierte Tool verfügbar, nicht an ein OEM-spezifisches VCI oder eine Toolkette gebunden.

Kontrollierter, überprüfbarer Zugriff — OEMs behalten die Kontrolle

Ein kritischer Punkt, der hervorgehoben werden sollte: SOVD öffnet niemandem die Fahrzeugdiagnose. OEMs behalten die volle Kontrolle über die Autorisierung über OAuth 2.0 und OpenID Connect — dieselben Sicherheitsstandards, die in der gesamten Unternehmenssoftware verwendet werden. Die rollenbasierte Zugriffskontrolle bestimmt genau, was die einzelnen Clienttypen tun können. Eine unabhängige Werkstatt erhält Zugriff auf Fehlercodes und definierte Diagnoseroutinen. Ein OEM-Techniker erhält umfassenderen Zugriff auf Kalibrierungs- und Debug-Funktionen. Ein Flottenbetreiber sieht Zustands- und Statusdaten.

Was sich ändert, ist nicht, wer den Zugriff kontrolliert - OEMs tun das immer noch -, sondern wie dieser Zugriff verwaltet wird. Eine standardisierte, protokollierte, überprüfbare API ersetzt einen fragmentierten Satz proprietärer Integrationen, die sich in großem Maßstab nur schwer verwalten lassen.

Überbrückung älterer Steuergeräte und HPC-basierter Architekturen

SOVD erfordert keinen Austausch der vorhandenen ECU-Infrastruktur. Ein klassischer Diagnoseadapter übernimmt die Übersetzung zwischen SOVD-Anfragen und UDS-Befehlen für herkömmliche Steuergeräte — ältere Systeme funktionieren weiter. Neue HPC-basierte Anwendungen können Diagnosen nativ über SOVD bereitstellen. Das Tool der unabhängigen Werkstatt kommuniziert mit einer Schnittstelle; das Fahrzeug übernimmt das Routing intern. Dies macht eine schrittweise Einführung ohne ein Komplettprogramm realistisch.

Compliance-Nachweise als Nebenprodukt

UN R156 verlangt von OEMs die Wartung von Software-Update-Managementsystemen mit strukturierten Nachweisen darüber, wie Updates geplant, ausgeführt und validiert werden. Die standardisierten, protokollierten API-Interaktionen von SOVD generieren diese Beweise auf natürliche Weise. Softwareinventar, Bereitschaftsprüfungen, Validierung nach dem Update und Auditprotokolle sind Ergebnisse des normalen SOVD-Betriebs — keine separate forensische Übung, die zum Zeitpunkt der Konformitätsprüfung durchgeführt wurde.

Der Vorteil des Händler- und Servicenetzes

Neben der Einhaltung gesetzlicher Vorschriften bietet SOVD auch den Mehrwert, den es Händlern und unabhängigen Servicenetzwerken, die SDVs warten, ermöglicht. Hier wird der betriebliche ROI konkret.

Vor dem Werkstattbesuch per Fernzugriff

Der zentrale OEM-Support kann über SOVD auf Fahrzeuge zugreifen, bevor sie zur Wartung eintreffen. Er ruft Protokolle ab, identifiziert Fehlermuster, konfiguriert die hochauflösende Datenerfassung und löst Probleme in vielen Fällen ohne einen physischen Besuch. Wenn ein Werkstattbesuch erforderlich ist, kommt der Techniker mit Kontext und nicht mit einem leeren Blatt. Die Quoten für erstmalige Reparaturen verbessern sich. Unnötiger Austausch von Teilen nimmt ab. Die Garantiekosten sinken.

Tools für Händler, die mit den Software-Updates Schritt halten

Im softwaredefinierten Fahrzeug kann sich das Diagnoseprofil des Autos mit jedem OTA-Update ändern. Die sich selbst beschreibende Architektur von SOVD bedeutet, dass die Tools des Händlers die aktuellen Fahrzeugfunktionen zur Laufzeit erkennen, anstatt sich auf statische Beschreibungsdatenbanken zu verlassen, die möglicherweise bereits veraltet sind. Die Händler arbeiten an dem Fahrzeug, das heute existiert, und nicht an einem Software-Snapshot von vor sechs Monaten.

Aktivierung unabhängiger Werkstätten ohne IP-Risiko

Eine der Kernfragen im Zusammenhang mit dem Recht auf Reparatur war schon immer: Wie bietet man aussagekräftigen Diagnosezugriff, ohne proprietäre Kalibrierungssoftware, Steuergerätecode und hochwertige Algorithmen preiszugeben? SOVD begegnet diesem Problem durch Service-Kapselung. Die API stellt dar, was eine Werkstatt zur Diagnose und Wartung des Fahrzeugs benötigt — Fehlercodes, Messwerte, definierte Testroutinen — ohne die zugrunde liegende Softwareimplementierung preiszugeben. OEMs definieren die Grenzen der Diagnoseservices; SOVD setzt sie durch.

Skalierbarer Zugang für Flottenbetreiber

Flottenbetreiber stehen für einige der anspruchsvollsten Serviceszenarien: hohe Fahrzeugzahlen, ausfallkritische Betriebsabläufe, geografisch verteilte Flotten. SOVD ermöglicht die Überwachung des Zustands auf Flottenebene über dieselbe API, die für die individuelle Fahrzeugdiagnose verwendet wird. Dabei werden Fehlermuster zusammengefasst, Softwareversionen in der gesamten Flotte nachverfolgt und proaktive Serviceanforderungen aufgedeckt, bevor sie zu Ausfällen führen.

Sibros SOVD: Von der Bewertung zur Produktion
‍Sibros hat eine komplette gebaut SOVD-Angebot - deckt sowohl die Serverfunktionen im Fahrzeug als auch Cloud-/Backoffice-Tools ab und wurde für OEMs entwickelt, die von der Architekturbewertung zur Serienbereitstellung übergehen. Unser Angebot umfasst:

• SOVD-Kunde und Admin-Plattform: rollenbasierte Zugangskontrolle, Fern- und Näherungsdiagnose-Workflows sowie strukturierte Auditprotokollierung über den gesamten Fahrzeuglebenszyklus hinweg.
• Integration von Fertigung und Kundendienst: dieselbe SOVD-Infrastruktur unterstützt die Konfiguration am Ende der Fertigungslinie, die Tools für den Händlerservice und die Fernüberwachung der Flotte ohne separate Implementierungen.
• OTA- und Logging-Ökosystem: SOVD-Diagnose und Verwaltung von Softwareupdates arbeiten Sie zusammen mit Sibros von einer einheitlichen Infrastruktur aus Tiefer Logger und OTA-Funktionen.
• SOVD-Beratungsleistungen: für OEMs, die Architekturentscheidungen bewerten, den Umfang der Lieferantenanforderungen festlegen oder die schrittweise Einführung von SOVD in allen Fahrzeugprogrammen planen. ‍

‍Das Recht der EU, die Einhaltung der Vorschriften zu korrigieren, ist seit dreißig Jahren die Grundlage. Was sich ändert, ist das Fahrzeug — und damit auch die architektonischen Anforderungen, die erforderlich sind, um die Einhaltung der Vorschriften in großem Umfang über softwaredefinierte Flotten hinweg zu gewährleisten. OEMs, die eine Diagnoseinfrastruktur rund um SOVD aufbauen, lösen jetzt nicht nur ein Compliance-Problem. Sie schaffen die Grundlage für den Servicebetrieb für die SDV-Ära.