Fahrzeugferndiagnose: Ein technischer Vergleich von drei Ansätzen

Moderne Fahrzeuge stützen sich auf hochkomplexe Software – und genau das stellt viele Werkstätten vor erhebliche Herausforderungen. Die Fahrzeugferndiagnose löst dieses Problem, indem sie Fahrzeuge vor Ort mit spezialisierten Experten aus der Ferne verbindet. Doch nicht alle technischen Ansätze sind gleichwertig. Dieser Leitfaden erläutert drei grundlegende Architekturen: Remote-Desktop-Steuerung, OBD-II-Hardware-Relay und softwarebasiertes VCI-Mapping. Ob Werkstatt auf der Suche nach der richtigen Ausrüstung oder Spezialist, der seine Kapazitäten ausbauen möchte – hier erfahren Sie, wie sich die Methoden in Bezug auf technische Leistung, Kosten und OEM-Tool-Kompatibilität unterscheiden.

1. Warum Fahrzeugferndiagnose heute unverzichtbar ist

Ein modernes Premiumfahrzeug enthält 80 oder mehr Steuergeräte (ECUs). Motor, Getriebe, Fahrwerk, Karosserie und Infotainment bilden jeweils eigene vernetzte Softwaredomänen, die über CAN, LIN, MOST, FlexRay und zunehmend auch Automotive Ethernet kommunizieren. Die Firmware eines aktuellen Flaggschiffmodells kann in der Summe über 100 Millionen Codezeilen umfassen – mehr als die Softwareinfrastruktur eines Verkehrsflugzeugs.

Wenn in dieser komplexen Systemlandschaft etwas schiefläuft – oder wenn ein Steuergerät ersetzt, codiert oder neu kalibriert werden muss – ist die Reparatur im Kern eine Softwareaufgabe. ADAS-Sensorkalibrierung, Kalibrierung des Hochvolt-Batteriemanagementsystems, Gateway-Sicherheitszugriff und das Zurücksetzen von Over-the-Air-Updates erfordern Spezialwerkzeuge und zertifizierte Fachkenntnisse, die sich die meisten freien Werkstätten schlicht nicht leisten können.

Die Fahrzeugferndiagnose löst dieses Problem, indem die OBD-II-Schnittstelle über das Internet zugänglich gemacht wird. Ein zertifizierter Kfz-Elektronikspezialist (im Folgenden: Techniker) kann OEM-Diagnosesoftware ausführen, Live-Datenströme auslesen, geführte Fehleranalysen durchführen und ECU-Firmware aus seinem Büro heraus flashen – ohne zum Fahrzeug anreisen zu müssen. Der Mechaniker in der Werkstatt verbindet lediglich das Diagnosegerät mit dem Fahrzeug und sorgt für eine stabile Internetverbindung. Den Rest erledigt der Techniker aus der Ferne.

Dieses Modell verändert bereits heute, wie Diagnose-Know-how eingekauft und angeboten wird. Die Frage lautet nicht mehr ob, sondern auf welcher technischen Grundlage die Ferndiagnose aufgebaut werden soll.

2. Die drei Architekturen im Überblick

Es gibt drei grundlegende Ansätze für die Fahrzeugferndiagnose. Jeder unterscheidet sich im Datenpfad, in der Kostenstruktur und in den technischen Rahmenbedingungen. Wer die richtige Methode für seine Situation wählen möchte, muss die jeweilige Architektur verstehen.

Methode 1: Remote-Desktop-Steuerung der Diagnosesoftware vor Ort

Funktionsweise

Der Mechaniker verbindet einen herstellereigenen OEM-VCI – beispielsweise ein BMW-ENET-Interface, das Ford VCM III oder den VW VAS 6154A – mit der OBD-II-Buchse des Fahrzeugs und mit einem lokalen Windows-PC, auf dem die OEM-Diagnosesoftware installiert ist. Der Techniker nutzt anschließend ein Bildschirmfreigabe-Tool wie TeamViewer oder AnyDesk, um diesen PC fernzusteuern.

Datenpfad:

Fahrzeug → OEM-VCI (proprietäres USB/Ethernet) → Werkstatt-PC mit OEM-Software → Bildschirmübertragung → Bildschirm des Technikers

Technische Besonderheiten

• Alle Diagnose- und Programmiervorgänge werden lokal auf dem Werkstatt-PC ausgeführt. Der Techniker sieht die Benutzeroberfläche der OEM-Software und gibt Anweisungen, aber die eigentlichen Befehle werden vom lokalen Rechner an das Fahrzeug gesendet. Bildschirmlatenz beeinträchtigt weder die Programmiersicherheit noch die Datenintegrität – sie wirkt sich lediglich auf die Reaktionsgeschwindigkeit der Anzeige aus.

• Bildschirmfreigabe-Protokolle (RDP, VNC, TeamViewer) können bei mittlerer Netzwerkauslastung eine wahrnehmbare Verzögerung von 100–400 ms verursachen, die den Arbeitsrhythmus des Technikers verlangsamt, ohne jedoch den ECU-Flash-Vorgang zu gefährden.

• Die OEM-Software auf dem Werkstatt-PC muss über eine gültige Lizenz verfügen. Viele OEM-Plattformen – etwa VW ODIS oder BMW ISTA – nutzen hardwaregebundene Dongles, sodass die Lizenz nicht auf den Techniker-PC übertragen werden kann.

• Diese Methode erfüllt vollständig die Anforderungen der OEM-Sicherheits-Gateways, da der OEM-VCI und die Software physisch vor Ort verbleiben.

Vorteile

• Keinerlei Kompatibilitätsrisiko: Das OEM-Tool läuft nativ vor Ort – einschließlich aller proprietären SCN-Codierungen, Variantencodierungen und geführten Funktionen.

• Vertraute Arbeitsumgebung: Der Techniker arbeitet in genau der OEM-Softwareumgebung, auf der er zertifiziert ist – ohne Protokollumsetzung oder zwischengeschaltete Middleware.

• Geeignet für komplexe Einzelaufgaben – etwa den Austausch eines Gateway-Moduls mit Sicherheitszugriff – bei denen die Werkstatt bereits über das entsprechende Equipment verfügt.

Nachteile

• Hohe Anfangsinvestition: Jede OEM-Marke erfordert einen eigenen VCI und eine eigene Softwarelizenz. Eine Mehrmarkenwerkstatt benötigt möglicherweise zehn oder mehr Toolsets, jeweils mit laufenden Abogebühren.

• Präsenz vor Ort erforderlich: Ein Mechaniker muss physisch anwesend sein, um VCI und PC zu bedienen – unbemannte oder außerhalb der Öffnungszeiten durchgeführte Sitzungen sind nicht möglich.

• Bildschirmlatenz mindert die Effizienz: Auch wenn das Fahrzeug nicht gefährdet wird, kann eine träge Bildschirmreaktion die Arbeitsgeschwindigkeit des Technikers spürbar senken – besonders bei langen Programmiersessions mit vielen Interaktionsschritten.

• Aufwendige Terminkoordination: Die Abstimmung zwischen dem Mechaniker vor Ort und dem Techniker an einem anderen Standort – über Zeitzonen, Softwareversionen und Remote-Tool-Kompatibilität hinweg – erhöht den organisatorischen Aufwand jeder Sitzung erheblich.

Methode 2: OBD-II-Hardware-Relay

Funktionsweise

Ein dediziertes Relay-Gerät wird in der Werkstatt an die OBD-II-Buchse des Fahrzeugs angeschlossen. Dieses Gerät verbindet sich mit dem Internet und kommuniziert mit einem gepaarten Relay-Gerät am Arbeitsplatz des Technikers. Das entfernte Gerät stellt dem Techniker-PC einen virtuellen OBD-II-Port bereit. Der Techniker verbindet seinen eigenen VCI und seine Diagnosesoftware mit diesem virtuellen Port – so, als wäre das Fahrzeug lokal angeschlossen.

Anbieter dieser Architektur sind u. a. Opus IVS und asTech, die jeweils aufeinander abgestimmte Gerätepaarungen zusammen mit eigenen Managed-Service-Plattformen anbieten.

Datenpfad:

Fahrzeug → Relay-Box A (Werkstatt, Mechaniker-Seite) → Internet (Anbieter-Cloud) → Relay-Box B (entfernt, Techniker-Seite) → VCI des Technikers + OEM-Diagnosesoftware

Technische Besonderheiten

• Die Relay-Hardware vor Ort muss alle fahrzeugseitigen physikalischen Schichten abbilden – CAN High/Low, K-Line, ISO-15765-Framing – und diese für den IP-Transport neu verpacken. Die Protokolltreue hängt vollständig von der Firmware-Qualität des Anbieters ab.

• Die Round-Trip-Latenz liegt bei guter Breitbandverbindung typischerweise bei 20–80 ms, wobei der Cloud-Relay des Anbieters einen variablen Hop außerhalb Ihrer Kontrolle hinzufügt.

• Neue Fahrzeugplattformen – beispielsweise solche mit UDS-over-DoIP-Architektur – erfordern Firmware-Updates der Relay-Hardware, bevor sie diagnostiziert werden können. Das führt zu einer Unterstützungsverzögerung von Wochen bis Monaten nach der Markteinführung neuer Modelle.

Vorteile

• Geringer Aufwand in der Werkstatt: Der Mechaniker benötigt keine OEM-Software oder Diagnosekenntnisse – einfach Relay-Box anschließen und mit dem Internet verbinden.

• Techniker nutzt eigene Tools: Alle OEM-Software, Lizenzen und VCIs verbleiben am Arbeitsplatz des Technikers, wo sie ordnungsgemäß gepflegt und aktuell gehalten werden.

Nachteile

• Strenge Gerätekopplung: Werkstatt und Techniker müssen zwingend die aufeinander abgestimmten Geräte desselben Anbieters verwenden. Kompatibilität zwischen verschiedenen Herstellern oder Plattformen ist nicht möglich.

• Kosten pro Diagnosesitzung: Die meisten Anbieterplattformen berechnen Gebühren pro Diagnoseereignis. Bei hohem Aufkommen summieren sich diese Kosten rasch und belasten die Marge.

• Protokollabdeckung hinkt neuen Fahrzeugen hinterher: Jedes neue OBD-II-Kommunikationsprotokoll erfordert ein Firmware-Update beider Relay-Geräte, bevor die Methode für diesen Fahrzeugtyp einsetzbar ist.

• Anbieterabhängigkeit: Fällt die Cloud-Plattform des Anbieters aus, sind sämtliche Remote-Sitzungen nicht verfügbar – unabhängig von der lokalen Verbindungsqualität.

Methode 3: Softwarebasiertes VCI-Mapping über USB / Ethernet (eLinehub)

Funktionsweise

Ein handelsüblicher VCI – mit Unterstützung für J2534 Pass-Thru (SAE J2534-1/2), D-PDU API (ISO 22900-2) oder DoIP (ISO 13400-2) – wird an die OBD-II-Buchse des Fahrzeugs und per USB oder Ethernet an einen Windows-PC oder ein Laptop auf der Mechaniker-Seite angeschlossen. Der schlanke eLinehub-Agent auf der Mechaniker-Seite läuft auf diesem Werkstatt-PC und baut einen verschlüsselten Tunnel zum Windows-Arbeitsplatz des Technikers auf. Auf der Techniker-Seite installiert der eLinehub-Client einen virtuellen Gerätetreiber, der den VCI so abbildet, als wäre er physisch angeschlossen. Die OEM-Diagnosesoftware des Technikers – ISTA, IDS, GDS2, ODIS, Techstream oder jede andere J2534/D-PDU-konforme Anwendung – kommuniziert mit dem virtuellen VCI, ohne dass Anpassungen erforderlich sind.

Datenpfad:

Fahrzeug → Standard-VCI (USB oder Ethernet) → Werkstatt-PC (eLinehub-Mechaniker-Agent) → TLS-1.3-verschlüsselter Tunnel → Techniker-PC (eLinehub virtueller VCI-Treiber) → OEM-Diagnosesoftware

Remote Diagnostics Method – VCI Interface Mapping (USB & Ethernet)

Technischer Hintergrund: Warum USB-Weiterleitung nahezu lokale Leistung erreicht

USB-2.0-Bulk-Transfers arbeiten mit bis zu 480 Mbps bei einem maximalen Abfrageintervall von 5 ms. eLinehub erfasst Bulk-Transfer-URBs (USB Request Blocks) auf Treiberebene und kapselt sie in einem schlanken binären Framing-Protokoll, das über einen TLS-1.3-Tunnel übertragen wird. Da der virtuelle Treiber des Technikers denselben USB-Gerätedeskriptor (VID/PID) präsentiert, lädt die vorhandene J2534-DLL des OEM-Tools ohne Modifikation – und verhält sich so, als wäre der VCI physisch angeschlossen.

Bei Ethernet/DoIP-VCIs ist die Architektur noch einfacher: DoIP ist von Haus aus IP-nativ (UDP für Fahrzeugankündigung, TCP für Diagnosesitzungen gemäß ISO 13400-2). eLinehub leitet die DoIP-TCP-Sitzung weiter, sodass keine Protokollkonvertierung stattfindet. Die OEM-Software des Technikers öffnet einen Standard-TCP-Socket und empfängt echte DoIP-Frames direkt vom Gateway-Modul des Fahrzeugs.

Gemessener Overhead: Im typischen Betrieb über eine 50-Mbps-Breitbandverbindung fügt eLinehub der reinen USB-Roundtrip-Zeit weniger als 8 ms hinzu – die Gesamtlatenz bleibt damit deutlich unter dem 50-ms-Schwellenwert, der für stabile ECU-Flash-Sitzungen erforderlich ist.

OEM-Tool-Kompatibilität

Da der virtuelle VCI standardmäßige J2534- oder D-PDU-API-Schnittstellen bereitstellt, funktionieren alle OEM-Plattformen, die diese Standards unterstützen, ohne zusätzliche Konfiguration. Bestätigte kompatible Tools umfassen:

• BMW ISTA (ISTA/D und ISTA/P) über ENET- oder ICOM-VCI

• Ford / Mazda IDS und FDRS über VCM II / VCM III

• GM GDS2 über MDI2-Interface

• VW-Gruppe ODIS-S und ODIS-E über VAS 6154A / VCP

• Toyota / Lexus Techstream über TIS-Techstream-VCI

• Mercedes-Benz XENTRY/DAS über DoIP-VEDOC-Gateway

• Alle Drittanbieter-Tools mit J2534-konformer DLL (Autel, Launch, Snap-on u. a.)

Sicherheitsarchitektur

Der gesamte Datenverkehr zwischen dem Mechaniker-Agenten und dem Techniker-Arbeitsplatz ist mit TLS 1.3 und gegenseitiger Zertifikatsauthentifizierung verschlüsselt. Rohe Fahrzeugdaten werden auf den Servern von eLinehub weder gespeichert noch protokolliert – die Plattform arbeitet als zustandsloser Relay. Alle Sitzungsschlüssel sind ephemer (ECDHE-Forward-Secrecy), sodass auch ein kompromittierter Langzeitschlüssel keine historischen Sitzungen entschlüsseln kann.

Vorteile

• Keine proprietäre Remote-Hardware: Jeder in der Werkstatt vorhandene J2534/D-PDU-API-VCI kann genutzt werden – keine herstellergebundene Relay-Box erforderlich.

• Vollständige OEM-Tool-Kompatibilität: Funktioniert nativ mit allen gängigen OEM-Diagnoseplattformen – ohne Middleware oder Protokollkonvertierung.

• Latenzoptimiert für ECU-Programmierung: Weniger als 8 ms zusätzlicher Overhead; Gesamtlatenz unter 50 ms bei Standard-Breitbandverbindung.

• Abonnementbasierte Preisgestaltung: Ein einzelnes Abonnement deckt unbegrenzte Verbindungen pro Fahrzeug innerhalb eines 24-Stunden-Fensters ab – kalkulierbar auch bei hohem Sitzungsvolumen.

• Sofortige Unterstützung neuer Fahrzeugprotokolle: DoIP-native Fahrzeuge werden unterstützt, sobald das OEM-Tool dies tut – kein Warten auf Relay-Firmware-Updates.

• Kein aufwendiges Software-Setup auf der Mechaniker-Seite: Der eLinehub-Mechaniker-Agent ist schlanck und erfordert keine Installation von OEM-Diagnosesoftware in der Werkstatt.

Einschränkungen

• Kompatibler VCI erforderlich: Die Werkstatt benötigt einen VCI mit J2534- oder D-PDU-API-Unterstützung. Für Werkstätten, die eine neue Marke aufnehmen, ist dies eine einmalige Hardwareinvestition.

• Derzeit Windows auf beiden Seiten erforderlich: Android-Unterstützung für die Mechaniker-Seite ist in der Entwicklung.

• Stabile Internetverbindung vorausgesetzt: Für ECU-Programmiersitzungen wird eine Upload-Geschwindigkeit von mindestens 10 Mbps empfohlen.

3. Technischer Vergleich auf einen Blick

Kriterium	Remote-Desktop	OBD-II-Hardware-Relay	VCI-Mapping (eLinehub)
Anfangsinvestition	Hoch (OEM-Lizenzen + PC je Marke)	Mittel (aufeinander abgestimmte Gerätepaare)	Gering (nur VCI, einmalig)
Laufende Kosten	OEM-Software-Abonnements	Kosten pro Diagnosesitzung	Abonnement (planbar)
Protokollunterstützung	Abhängig von lokaler Software	Erfordert Anbieter-Firmware-Updates	CAN / DoIP / UDS nativ
OEM-Tool-Kompatibilität	Vollständig (lokale Software)	Nur anbieterspezifisch	J2534 / D-PDU API – vollständig
Programmiersicherheit	Nicht durch Bildschirmlatenz betroffen	Standard	Standard
Zusätzliche Latenz	Nur Bildschirm-Lag (kein ECU-Risiko)	20–80 ms + Cloud-Hop	< 8 ms Overhead
Vor-Ort-Bedarf	Mechaniker + PC + OEM-Software	Mechaniker + Relay-Box	Mechaniker + Windows-PC
Anbieterabhängigkeit	Mittel	Hoch (aufeinander abgestimmte Geräte)	Keine (offener Standard)
Neue Protokolle	Sofort (per Software-Update)	Verzögert (Firmware-Update-Zyklus)	Sofort (IP-nativ)
Betriebssystem	Beliebig (Remote-Desktop)	Anbieterspezifisch	Windows (Android in Planung)

4. Welche Methode passt zu Ihrem Anwendungsfall?

Freie Werkstätten und Mehrmarkenbetriebe

VCI-Mapping ist für freie Werkstätten die praktischste Lösung. Die meisten Betriebe besitzen bereits J2534-kompatible VCIs für die Marken, die sie warten. Die Installation des eLinehub-Mechaniker-Agenten auf dem vorhandenen Werkstatt-PC macht die bestehende Hardware sofort ferndiagnosefähig – ohne zusätzliche Hardwareinvestition und ohne auftragsbasierte Abrechnungskosten, die mit dem Volumen ansteigen.

Kfz-Elektronikspezialisisten und Anbieter von Fernkalibrierungen

eLinehub wurde speziell für Techniker entwickelt, die ihr Ferndiagnose-Angebot skalieren möchten. Anstatt zu jeder Werkstatt zu fahren, arbeiten Sie von einem zentralen Windows-Arbeitsplatz aus mit Ihren bevorzugten OEM-Diagnoseprogrammen. Ein einzelner Techniker kann über die Plattform mehrere Werkstätten gleichzeitig betreuen – jedes Fahrzeug verbraucht dabei unabhängig von der Anzahl der Verbindungen innerhalb eines 24-Stunden-Zeitfensters nur ein Credit. Die einheitliche Virtual-VCI-Architektur bedeutet: eine saubere Softwareumgebung statt der Verwaltung mehrerer Remote-Desktop-Sitzungen mit unterschiedlichen Werkstatt-PC-Konfigurationen.

Flottenoperatoren und Händlergruppen

VCI-Mapping beseitigt die Notwendigkeit, jedes Fahrzeug für Programmiervorgänge zu einer zentralen Einrichtung zu bringen. Ein Mechaniker mit VCI und Laptop kann eine Remote-Sitzung von jedem Depot oder jedem Standort aus starten, während der OEM-zertifizierte Techniker des Fuhrparks die Softwarearbeit zentral erledigt – Fahrzeugausfallzeiten und Reisekosten werden gleichzeitig reduziert.

Mobile Diagnose-Anbieter

Auf der Mechaniker-Seite genügt ein leichter Windows-Laptop mit einem kompakten J2534-VCI. Der Techniker übernimmt die gesamte Diagnosekomplexität aus der Ferne; die Aufgabe des mobilen Mechanikers beschränkt sich darauf, den VCI anzuschließen und eine stabile Verbindung aufrechtzuerhalten. Sobald Android-Unterstützung verfügbar ist, kann die Mechaniker-Seite von einem Tablet aus bedient werden – mit noch geringerem Gerätebedarf vor Ort.

5. Häufig gestellte Fragen

F: Welche Netzwerklatenz ist für die Fernprogrammierung von Steuergeräten akzeptabel?

A: Für die meisten ECU-Flash-Vorgänge sollte die Ende-zu-Ende-Latenz unter 50 ms bleiben. Die VCI-Mapping-Schicht von eLinehub fügt bei einer Standard-Breitbandverbindung weniger als 8 ms hinzu und hält die Gesamtroundtrip-Zeit damit weit innerhalb der sicheren Betriebsgrenzen aller gängigen OEM-Programmierverfahren.

F: Welche OEM-Diagnosestandards unterstützt eLinehub?

A: eLinehub ist kompatibel mit SAE J2534 Pass-Thru, D-PDU API (ISO 22900-2) und DoIP (ISO 13400-2). Das bedeutet: Sie können ISTA (BMW), IDS (Ford/Mazda), GDS2 (GM), ODIS (VW-Gruppe), Techstream (Toyota), XENTRY (Mercedes-Benz) und andere OEM-Plattformen ohne jegliche Middleware-Konvertierung betreiben.

F: Benötige ich für jede Fahrzeugmarke einen eigenen VCI?

A: Die meisten Multiprotokoll-VCIs decken die OEM-Protokolle der Mehrzahl der Hersteller über J2534 ab. Markeneigene VCIs sind in der Regel nur für proprietäre Varianten der physikalischen Schicht erforderlich. eLinehub pflegt eine aktuelle VCI-Kompatibilitätsliste, die mit neuen Modellen und Firmware-Versionen fortlaufend aktualisiert wird.

F: Wie werden Fahrzeugdaten während einer Remote-Sitzung geschützt?

A: Der gesamte Datenverkehr zwischen dem Mechaniker-Agenten und dem Techniker-Arbeitsplatz ist mit TLS 1.3 und gegenseitiger Zertifikatsauthentifizierung verschlüsselt. eLinehub fungiert als zustandsloser Relay – rohe ECU-Daten oder Fahrzeuginformationen werden auf den Servern von eLinehub weder gespeichert noch protokolliert. Alle Sitzungsschlüssel sind ephemer (ECDHE), sodass auch bei einer Kompromittierung des Langzeitschlüssels keine historischen Sitzungen entschlüsselt werden können.

F: Kann ich eLinehub über eine Mobilfunkverbindung nutzen?

A: Ja. Für ECU-Programmiervorgänge wird eine stabile Verbindung mit mindestens 10 Mbps Upload-Geschwindigkeit empfohlen. Standarddiagnosen und das Auslesen von Fehlercodes funktionieren auf den meisten 4G/LTE-Verbindungen zuverlässig. Bei großen Firmware-Flash-Dateien ist eine kabelgebundene oder WLAN-Verbindung zu bevorzugen, um Timeout-Fehler zu vermeiden.

6. Fazit

Fahrzeugferndiagnose ist längst kein Nischenthema mehr – sie entwickelt sich zur Grundvoraussetzung für jeden Kfz-Betrieb, der an modernen softwaredefinierten Fahrzeugen arbeitet. Die drei hier verglichenen Architekturen zeigen eine klare Entwicklungslinie: von der Remote-Desktop-Notlösung (Methode 1) und herstellergebundenen Hardware-Relay-Paaren (Methode 2) hin zum offenstandard-basierten, protokollnativen Ansatz des softwarebasierten VCI-Mappings.

Die eLinehub-Implementierung wurde speziell für die Latenz- und Sicherheitsanforderungen der ECU-Programmierung entwickelt. Durch den Betrieb auf den USB/IP- und DoIP-Transportschichten vermeidet sie den Protokollkonvertierungs-Overhead, der konkurrierende Lösungen limitiert. Für Kfz-Werkstätten bedeutet das: geringere Gesamtbetriebskosten und die Möglichkeit, Fernprogrammierung als eigenständige Dienstleistung anzubieten. Für Kfz-Elektronikspezialisisten bietet die Plattform eine skalierbare, professionell wartbare Techniker-Umgebung für den Aufbau eines Ferndiagnose-Geschäfts – ohne Reisen, ohne Anbieterabhängigkeit und ohne überraschende Kosten pro Sitzung.

Um eLinehub mit Ihrem vorhandenen VCI und Ihren OEM-Tools in der Praxis zu erleben, fordern Sie eine kostenlose Testversion auf elinehub.com an.