SOVD and EU Right to Repair: Building Scalable & Compliant Diagnostic Access Architecture for SDVs

Most OEMs operating in EU markets already know about the Right-to-Repair compliance. The Motor Vehicle Block Exemption Regulation (MVBER) has required non-discriminatory diagnostic access for independent repairers since 1995. This isn't a new regulation bearing down on the industry - it's an established baseline that has shaped how European automotive markets operate for three decades.

What has changed is the vehicle. Software-defined vehicles - with centralized HPCs, containerized applications, remote OTA updates, and cloud-connected service workflows - are making traditional diagnostic architectures increasingly brittle. Approaches that technically satisfied MVBER requirements in the era of standalone ECUs and physical workshop access are struggling to scale into the SDV era.

The real question for OEMs today isn't whether to provide diagnostic access - they're already obligated to. It's whether their diagnostic architecture can actually deliver that access in a way that is manageable, secure, and operationally valuable as vehicle software complexity compounds. SOVD is the architectural answer, and its benefits extend well beyond regulatory compliance into how OEMs enable their dealer and independent service networks to work on increasingly software-driven vehicles.

The Compliance Baseline: What MVBER Actually Requires

The MVBER grants OEMs a carve-out from certain EU competition law requirements - including the right to operate franchised dealer networks - in exchange for a clear obligation: independent repairers must receive non-discriminatory access to technical data, diagnostic tools, and repair information on fair commercial terms.

This means OEMs cannot use proprietary diagnostic architectures to create de facto access barriers that favor authorized dealer networks over independent repairers. Access must be technically feasible, not just theoretically permitted. And as vehicles become more software-defined, 'technically feasible' is an increasingly demanding bar.

A concrete illustration: a major OEM has been exploring SOVD specifically because their proprietary diagnostics solution cannot be deployed in the EU in its current form. The issue isn't legal intent - it's architectural reality. Proprietary systems designed for dealer networks create access patterns that don't map cleanly to the non-discriminatory access MVBER requires, especially as diagnostics move into software and remote domains.

MVBER at a Glance

Active since 1995, extended through 2028. Requires OEMs to provide independent repairers access to vehicle repair and technical information on non-discriminatory terms comparable to what authorized dealer networks receive. Applies to all OEMs selling vehicles in EU markets, regardless of where the OEM is headquartered.

Why SDVs Make the Architecture Problem Harder

Traditional diagnostics were designed around a stable, distributed ECU architecture. Each ECU had fixed identifiers, static description files, and a known UDS implementation. Compliance meant publishing those interfaces - complex and imperfect, but achievable.

Software-defined vehicles break this model in several ways:

• Dynamic software configurations: Modern SDVs run containerized applications on HPCs. Software changes with every OTA update. The vehicle that shipped is not the vehicle in the field six months later. Static description files and fixed ECU maps can't keep pace.
  
• Remote and cloud-based service workflows: Diagnostics increasingly happen before the vehicle reaches a workshop - remote pre-triage, fleet health monitoring, OTA-triggered service alerts. Traditional physical-access diagnostic models weren't designed for this, and proprietary remote tunnels bolted onto legacy systems create fragmentation.
  
• Multi-stakeholder access requirements: MVBER requires access for independent repairers. Fleet operators need their own access too. OEM central support needs remote visibility. Dealer technicians need in-shop tools. Engineering teams need deep debug access. Managing all of these through proprietary, point-to-point integrations is not scalable.
  
• Audit and compliance evidence: Regulations like UN R156 require structured evidence for how software updates are managed. Assembling compliance packages from scattered logs across proprietary systems is increasingly untenable as fleet scale grows.

The result is that OEMs who built diagnostic architectures adequate for the previous vehicle generation are facing compounding technical debt precisely when their service and compliance obligations are expanding.

SOVD: The Architectural Foundation for Scalable Access

SOVD - Service-Oriented Vehicle Diagnostics - is an ASAM standard (progressing through ISO as ISO 17978) that defines an HTTP/REST-based API for vehicle diagnostics. Where traditional diagnostics required every tool to implement custom communication logic for every vehicle program, SOVD provides a common API contract. Diagnostic content - fault codes, measurements, configuration parameters, software update status - is exposed through standardized REST endpoints using JSON, with capabilities self-described via OpenAPI specifications.

For OEMs navigating EU compliance obligations and SDV service complexity simultaneously, SOVD addresses both through the same architectural investment.

One Interface Across All Access Scenarios

SOVD defines a unified API that works across remote (cloud-based), proximity (in-shop), and in-vehicle scenarios. An independent repairer connecting at the workshop, a fleet operator monitoring remotely, and an OEM support engineer doing pre-triage before a service visit all interact through the same logical interface - with access governed by role-based permissions, not by which proprietary tool stack they happen to have.

For MVBER compliance, this matters because the architecture inherently supports non-discriminatory access. The OEM defines authorization levels - who sees what - but the interface itself is standardized and available to any authorized tool, not locked to an OEM-specific VCI or tool chain.

Controlled, Auditable Access - OEMs Stay in Control

A critical point worth emphasizing: SOVD does not open vehicle diagnostics to anyone. OEMs retain full control over authorization through OAuth 2.0 and OpenID Connect - the same security standards used across enterprise software. Role-based access control determines exactly what each client type can do. An independent repairer gets access to fault codes and defined diagnostic routines. An OEM engineer gets deeper access to calibration and debug functions. A fleet operator sees health and status data.

What changes is not who controls access - OEMs still do - but how that access is managed. One standardized, logged, auditable API replaces a fragmented set of proprietary integrations that are difficult to govern at scale.

Bridging Legacy ECUs and HPC-Based Architectures

SOVD doesn't require replacing existing ECU infrastructure. A Classic Diagnostic Adapter handles translation between SOVD requests and UDS commands for traditional ECUs - legacy systems keep working. New HPC-based applications can expose diagnostics natively via SOVD. The independent repairer's tool talks to one interface; the vehicle handles routing internally. This makes phased adoption realistic without a rip-and-replace program.

Compliance Evidence as a Byproduct

UN R156 requires OEMs to maintain Software Update Management Systems with structured evidence for how updates are planned, executed, and validated. SOVD's standardized, logged API interactions generate this evidence naturally. Software inventory, readiness checks, post-update validation, and audit logs are outputs of normal SOVD operations - not a separate forensic exercise assembled at compliance review time.

The Dealer and Service Network Advantage

Beyond compliance, SOVD's deeper value is what it enables for dealer and independent service networks servicing SDVs. This is where the operational ROI becomes concrete.

Remote Pre-Triage Before the Workshop Visit

OEM central support can access vehicles through SOVD before they arrive for service - retrieving logs, identifying fault patterns, configuring high-resolution data capture, and in many cases resolving issues without a physical visit. When a workshop visit is necessary, the technician arrives with context, not a blank slate. First-time fix rates improve. Unnecessary parts replacements decrease. Warranty costs fall.

Dealer Tools That Keep Pace with Software Updates

In the software-defined vehicle, the diagnostic profile of the car can change with every OTA update. SOVD's self-describing architecture means dealer tools discover current vehicle capabilities at runtime rather than relying on static description databases that may already be outdated. Dealers work on the vehicle that exists today, not a software snapshot from six months ago.

Independent Repairer Enablement Without IP Exposure

One of the core tensions in the right to repair has always been: how do you provide meaningful diagnostic access without exposing proprietary calibration software, ECU code, and high-value algorithms? SOVD addresses this through service encapsulation. The API exposes what a repairer needs to diagnose and service the vehicle - fault codes, measurement values, defined test routines - without exposing the underlying software implementation. OEMs define the diagnostic service boundary; SOVD enforces it.

Scalable Access for Fleet Operators

Fleet operators represent some of the most demanding service scenarios: high vehicle counts, uptime-critical operations, geographically distributed fleets. SOVD enables fleet-level health monitoring through the same API used for individual vehicle diagnostics - aggregating fault patterns, tracking software versions across the fleet, and surfacing proactive service needs before they become breakdowns. 

Sibros SOVD: From Evaluation to Production
‍Sibros has built a full SOVD offering - covering both in-vehicle server capabilities and cloud/back-office tooling - designed for OEMs moving from architectural evaluation to production deployment. Our offering includes:

• SOVD Client and Admin platform: role-based access control, remote and proximity diagnostic workflows, and structured audit logging across the vehicle lifecycle.
• Manufacturing and after-sales integration: the same SOVD infrastructure supports end-of-line configuration, dealer service tools, and remote fleet monitoring without separate implementations.
• OTA and logging ecosystem: SOVD diagnostics and software update management work from a unified infrastructure alongside Sibros Deep Logger and OTA capabilities.
• SOVD consulting services: for OEMs evaluating architecture decisions, scoping supplier requirements, or planning phased SOVD adoption across vehicle programs. ‍

‍EU right to repair compliance has been the baseline for thirty years. What's changing is the vehicle - and with it, the architectural demands of delivering that compliance at scale across software-defined fleets. OEMs who build diagnostic infrastructure around SOVD now aren't just solving a compliance problem. They're building the service operations foundation for the SDV era.