Warum einfache Widerstände nicht mehr funktionieren
In der Frühzeit der Motorelektronik reichte ein präziser Widerstand, um dem Steuergerät einen angeschlossenen Sensor vorzugaukeln. Eine 100-Ohm-Last am Heizerstecker der Lambdasonde, ein Potentiometer am Temperatursensor-Eingang – fertig. Diese Zeiten sind vorbei. Moderne Fahrzeuge sind vernetzte Systeme, in denen dutzende Steuergeräte über den CAN-Bus (Controller Area Network) kommunizieren, Daten abgleichen und Plausibilitätsprüfungen durchführen. Ein Emulator, der nur einen einzelnen Sensorwert fälscht, wird von diesem Netzwerk innerhalb von Sekunden entlarvt.
Rechtlicher Hinweis: Alle in diesem Artikel beschriebenen Maßnahmen betreffen ausschließlich Fahrzeuge im reinen Motorsport-Einsatz auf geschlossenen Rennstrecken. Die Manipulation abgasrelevanter Systeme an Fahrzeugen im öffentlichen Straßenverkehr ist nach §19 StVZO unzulässig.
Der CAN-Bus: Das Nervensystem des Fahrzeugs
Architektur moderner Fahrzeug-Netzwerke
Ein modernes Fahrzeug hat nicht einen CAN-Bus, sondern mehrere:
Antriebs-CAN (Powertrain CAN): Hochgeschwindigkeits-Bus (500 kbit/s) für Motorsteuergerät, Getriebesteuergerät, ABS/ESP-Steuergerät. Hier laufen zeitkritische Daten wie Motordrehzahl, Drehmoment, Raddrehzahlen.
Komfort-CAN (Body CAN): Niedrigerer Geschwindigkeit (125–250 kbit/s) für Karosserie-Steuergeräte, Klimaanlage, Sitzverstellung. Im Motorsport-Kontext weniger relevant, aber nicht irrelevant – Fehlercodes im Body-CAN können Warnleuchten auslösen.
Diagnose-CAN (OBD-CAN): Über die OBD-II-Buchse zugänglich. Standardisierte Kommunikation nach ISO 15765 (CAN) und ISO 14229 (UDS – Unified Diagnostic Services).
Infotainment-CAN/MOST/Ethernet: Für Multimedia-Systeme. Im Motorsport meist deaktiviert oder entfernt.
CAN-Bus-Grundlagen für Emulator-Integration
Jede CAN-Nachricht (Frame) enthält:
- Arbitration ID: 11 oder 29 Bit, identifiziert den Absender und die Nachricht
- DLC: Data Length Code, gibt die Datenlänge an (0–8 Bytes bei CAN 2.0)
- Daten: Bis zu 8 Bytes Nutzdaten
- CRC: Prüfsumme zur Fehlererkennung
Entscheidend: CAN ist ein Broadcast-Bus. Jedes Steuergerät am Bus empfängt jede Nachricht und filtert lokal, welche Nachrichten es verarbeitet. Das bedeutet: Wenn ein Emulator eine Nachricht auf den Bus legt, sehen alle Steuergeräte diese Nachricht – nicht nur das eine, für das sie bestimmt ist.
Plausibilitätsprüfungen über den CAN-Bus
Steuergeräte-übergreifende Datenkorrelation
Moderne Motorsteuergeräte verlassen sich nicht allein auf ihre eigenen Sensoren. Sie empfangen zusätzliche Daten von anderen Steuergeräten über den CAN-Bus und vergleichen diese mit ihren lokalen Messwerten:
Beispiel Lambdasonde + Motorlast: Das Motorsteuergerät kennt die aktuelle Einspritzmenge (eigene Berechnung), die Luftmasse (eigener Sensor), den Lambda-Wert (eigener Sensor) und empfängt vom Getriebesteuergerät die aktuelle Gangstufe, vom ABS-Steuergerät die Fahrzeuggeschwindigkeit und vom Turbolader-Steuergerät den aktuellen Ladedruck. Aus all diesen Daten berechnet es einen erwarteten Lambda-Wert. Weicht der gemessene Lambda-Wert (oder der emulierte) signifikant vom berechneten ab, wird ein Plausibilitätsfehler gesetzt.
Beispiel Abgastemperatur + Kühlmitteltemperatur: Das Motorsteuergerät berechnet die erwartete Abgastemperatur basierend auf Einspritzmenge, Zündzeitpunkt (beim Benziner) bzw. Einspritztiming (Diesel), Luftmasse und Kühlmitteltemperatur. Die Kühlmitteltemperatur kommt teilweise über den CAN-Bus von einem separaten Kühlmittel-Steuergerät (bei BMW z. B. dem elektrischen Thermostat-Steuergerät). Stimmt die emulierte Abgastemperatur nicht zur realen Kühlmitteltemperatur, fällt die Diskrepanz auf.
Beispiel DPF-Differenzdruck + Fahrzustand: Das Motorsteuergerät empfängt vom ABS/ESP-Steuergerät die aktuelle Fahrzeuggeschwindigkeit und die Radbeschleunigung. Im Schubbetrieb (Geschwindigkeit > 0, kein Gas) erwartet es einen bestimmten Differenzdruck am DPF. Ein Emulator, der einen lastunabhängig konstanten Differenzdruck liefert, wird in diesem Betriebszustand als unplausibel erkannt.
Zeitliche Korrelation (Time-Domain Plausibility)
Nicht nur die Absolutwerte, sondern auch die zeitliche Abfolge wird überwacht:
Signalverzögerung: Wenn das Motorsteuergerät die Einspritzmenge ändert, erwartet es eine definierte Verzögerung, bis sich der Lambda-Wert ändert (Totzeit des Systems). Diese Totzeit ist abhängig von der Entfernung der Sonde zum Zylinder, dem Abgasvolumenstrom und der Sondenansprechzeit. Ein Emulator, der sofort oder zu spät reagiert, wird erkannt.
Aufheiz-Dynamik: Nach einem Kaltstart erwartet das Steuergerät einen spezifischen Temperaturanstieg der Abgassensoren. Dieser Anstieg korreliert mit der Kühlmitteltemperatur, der Motorlast und der Zeit seit Start. Ein Emulator, der sofort einen warmen Sensor meldet, ist unplausibel.
CAN-Nachrichtentiming: Jedes Steuergerät sendet seine CAN-Nachrichten in definierten Intervallen (typisch 10–100 ms). Wenn ein Emulator CAN-Nachrichten sendet, müssen Timing und Zykluszeit exakt stimmen. Ein fehlerhaftes Timing generiert einen CAN-Kommunikationsfehler.
Alive-Counter und Checksummen
Viele sicherheitsrelevante CAN-Nachrichten enthalten zusätzliche Sicherungsmechanismen:
Alive-Counter (Rolling Counter): Ein 4-Bit-Zähler, der mit jeder Nachricht inkrementiert wird (0→1→2→…→15→0). Empfangende Steuergeräte prüfen, ob der Zähler korrekt inkrementiert. Fehlt eine Nachricht oder wird eine doppelt gesendet, erkennt das empfangende Steuergerät dies.
Checksumme (CRC): Neben der CAN-eigenen CRC berechnen viele Hersteller eine zusätzliche Anwendungsschicht-Checksumme über die Nutzdaten. Der Algorithmus ist herstellerabhängig und teilweise auch nachrichtenabhängig. Ohne Kenntnis des Algorithmus kann ein Emulator keine gültige Nachricht erzeugen.
Timeout-Überwachung: Jedes Steuergerät überwacht, ob erwartete CAN-Nachrichten innerhalb eines definierten Zeitfensters eintreffen. Bleibt eine Nachricht aus (z. B. weil ein Sensor-Steuergerät entfernt wurde), wird ein Kommunikationsfehler gesetzt.
Folgefehler-Kaskaden: Wenn ein Fehler zehn weitere auslöst
Die gefährlichste Konsequenz einer unprofessionellen Emulator-Integration ist die Folgefehler-Kaskade. Ein einziger unplausibler Sensorwert kann eine Kette von Reaktionen in mehreren Steuergeräten auslösen:
Fallbeispiel: Fehlerhafte DPF-Emulation bei BMW N57
Auslöser: DPF-Differenzdrucksensor meldet konstant 0 mbar (Emulator liefert festes Signal).
Kaskade:
- DDE (Motorsteuergerät): Differenzdruck unplausibel bei Last → P244A (Differenzdrucksensor – Signal unplausibel)
- DDE: Setzt Rußmassen-Berechnung auf Ersatzwert → berechnet unkontrolliert steigende Rußmasse
- DDE: Leitet Regenerationsversuch ein → Nacheinspritzung aktiv → Kraftstoff im Abgasstrang
- DDE: Regeneration „erfolglos” (Differenzdruck ändert sich nicht) → Regenerationsfehler P2463
- DDE: Mehrfache erfolglose Regeneration → Serviceregeneration angefordert → Warnleuchte MIL
- DDE: Begrenzt Motorleistung (Notlauf Stufe 1) → max. 75 % Drehmoment
- DDE: CAN-Nachricht „Motormoment reduziert” → EGS (Getriebesteuergerät) empfängt
- EGS: Passt Schaltprogramm an reduziertes Moment an → härtere Schaltungen, eingeschränkte Gänge
- DSC (ABS/ESP): Empfängt reduziertes Motor-Soll-Moment → passt ESP-Eingriffsschwellen an
- Instrument Cluster: Empfängt MIL-Anforderung + Leistungsreduzierung → Warnleuchten, Textmeldung
Ergebnis: Ein einzelner unplausibler Druckwert führt zu Leistungsverlust, verändertem Schaltverhalten, angepassten ESP-Schwellen und einem Fahrzeug voller Fehlermeldungen. Im Motorsport-Einsatz inakzeptabel.
Fallbeispiel: Lambda-Emulator ohne Heizerlast bei Mercedes
Auslöser: Lambdasonden-Emulator ohne Heizerlast-Simulation an Nachkat-Position eines M274 (W205 C-Klasse).
Kaskade:
- ME (Motorsteuergerät): Heizerstrom Sonde 2 = 0 A → P0141 (Sonde 2 Heizkreis)
- ME: Sonde 2 als defekt markiert → Katalysator-Monitor kann nicht durchgeführt werden
- ME: OBD-Readiness Catalyst Monitor = „not ready” → MIL nach 2 Driving Cycles
- ME: Setzt Gemischregelung auf Open Loop (keine Nachkat-Korrektur)
- ME: Langzeit-Kraftstoffanpassung driftet → LTFT Bank 1 > +15 %
- ME: LTFT-Grenzwert überschritten → P0170 (Fuel Trim Malfunction)
- ME: Zusätzlicher Fehler → Motorleistung begrenzt → Notlauf
- SCR-Steuergerät (falls vorhanden): Empfängt fehlerhafte Lambda-Basis → SCR-Dosierung falsch
- NOx-Sensor: Misst erhöhte NOx durch Open-Loop-Betrieb → P229F (NOx-Grenzwert)
Ergebnis: Ein fehlender Heizerwiderstand von wenigen Ohm löst neun Fehlercodes in drei Steuergeräten aus.
XENTRY, ODIS und ISTA: Der entscheidende Vorteil
Was Herstellerdiagnose kann, was generische Scanner nicht können
Generische OBD-II-Scanner:
- Lesen standardisierte Fehlercodes (P0xxx, P2xxx)
- Zeigen OBD-Readiness-Status (ready/not ready)
- Zeigen Basis-Live-Daten (RPM, Temperatur, Lambda)
- Können Fehlerspeicher löschen
- Limitiert auf OBD-II-Scope (emissionsrelevante Daten)
Herstellerdiagnose (XENTRY/ODIS/ISTA):
- Lesen ALLE Fehlercodes (herstellerspezifisch + OBD-II)
- Zeigen erweiterte Freeze-Frame-Daten mit Betriebspunkt
- Zugriff auf ALLE Live-Daten (hunderte Parameter vs. dutzende)
- Adaptionswerte auslesen und gezielt zurücksetzen
- Steuergeräte-Software-Version und Kalibrierungsdaten lesen
- Aktive Stellgliedtests (Aktor-Tests) durchführen
- Geführte Diagnose-Routinen (Guided Fault Finding)
- Steuergeräte-spezifische Programmierung und Konfiguration
- CAN-Bus-Monitoring auf Applikationsebene
- OBD-Monitor-Detailergebnisse (nicht nur ready/not ready)
XENTRY (Mercedes-Benz): Der Gold-Standard
XENTRY ist das von Mercedes-Benz für seine Vertragswerkstätten entwickelte Diagnosesystem. Im Kontext der Emulator-Integration bietet es:
Komplette Steuergeräte-Übersicht: XENTRY zeigt den Status aller verbauten Steuergeräte, deren Software-Versionen und Kommunikationsstatus auf dem CAN-Bus. Damit lässt sich sofort erkennen, ob ein Emulator CAN-Kommunikationsfehler verursacht.
Erweiterte Sondenwerte: XENTRY zeigt nicht nur den Lambda-Wert, sondern auch den Innenwiderstand der Sonde, den Heizerstrom, die Heizer-PWM, die Sondentemperatur und den Alterungswert. So lässt sich prüfen, ob der Emulator alle Aspekte der Sonde korrekt simuliert.
Katalysator-Monitoring-Detail: Während ein OBD-Scanner nur „Catalyst Monitor: not ready” meldet, zeigt XENTRY den berechneten OSC-Wert (Oxygen Storage Capacity), die Schwellwerte, die Enabling Conditions und den Fortschritt des Monitor-Durchlaufs.
Adaptionswerte-Management: XENTRY ermöglicht das gezielte Zurücksetzen einzelner Adaptionswerte – nicht nur das globale „Fehlerspeicher löschen”. Nach einer Emulator-Integration müssen spezifische Adaptionen zurückgesetzt werden, während andere (z. B. Getriebeadaption) erhalten bleiben sollen.
ODIS (VW/Audi/Skoda/Seat): Tiefste Parametrierung
ODIS (Offboard Diagnostic Information System) bietet für die VW-Gruppe:
Messwerteblöcke: ODIS organisiert Live-Daten in sogenannten Messwerteblöcken (MWB). Für die Emulator-Verifikation relevant sind insbesondere die Blöcke für Lambda-Regelung (MWB 030-034), Abgastemperaturen (MWB 070-074), DPF-System (MWB 075-079) und AGR-System (MWB 080-084). Jeder Block zeigt 4 Werte mit Soll-Ist-Vergleich.
Anpassungskanäle: ODIS ermöglicht über Anpassungskanäle das gezielte Konfigurieren von Steuergeräteparametern. Im Emulator-Kontext relevant: Zurücksetzen von Langzeitadaptionen, DPF-Rußmassenzähler und AGR-Lernwerten.
Grundeinstellungen: Bestimmte Systeme erfordern nach einer Modifikation eine „Grundeinstellung” – eine vom Steuergerät geführte Kalibrierungsroutine. Beispielsweise muss die Drosselklappe nach einer AGR-Modifikation neu angelernt werden.
ISTA (BMW/Mini): Modellbasierte Diagnose
ISTA (Integrated Service Technical Application) ist das BMW-Diagnosesystem:
Statusübersicht: ISTA zeigt eine grafische Übersicht aller Steuergeräte mit Ampel-Status (grün/gelb/rot). Nach einer Emulator-Integration muss alles grün sein – ein einzelnes gelbes oder rotes Steuergerät deutet auf Folgefehler hin.
Messwerterfassung: ISTA ermöglicht die gleichzeitige Erfassung von Live-Daten aus mehreren Steuergeräten. Das ist entscheidend, um CAN-Bus-übergreifende Plausibilität zu prüfen: Stimmen die Motordaten im DME mit den Daten überein, die das DSC empfängt?
Fehlerspeicher-Detail: BMW-Fehlercodes enthalten mehr Information als nur den Code: Betriebszustand bei Auftreten, Umgebungsdaten (Freeze Frame), Häufigkeitszähler, Zeitstempel und Heilungsstatus. Diese Details sind entscheidend, um zu beurteilen, ob ein Fehler durch den Emulator verursacht wird oder ein vorbestehendes Problem ist.
Die professionelle CAN-Bus-Integration bei KFZ Dietrich
Vor der Integration: Baseline-Aufnahme
- Vollständiger Fehlerspeicher-Scan: Alle Steuergeräte, nicht nur das Motorsteuergerät
- CAN-Bus-Kommunikation prüfen: Alle Steuergeräte ansprechbar, keine Timeout-Fehler
- Live-Daten-Baseline: Aufzeichnung aller emissionsrelevanten Parameter bei verschiedenen Betriebspunkten
- Adaptionswerte dokumentieren: Alle relevanten Langzeitadaptionen sichern
- Software-Versionen notieren: Wichtig für die Auswahl des passenden Emulators
Integration und sofortige Verifikation
- Emulator-Einbau mit korrekter CAN-Bus-Anbindung (falls CAN-aktiver Emulator)
- Erster Diagnose-Scan: Sofortige Prüfung auf neue Fehlercodes
- CAN-Bus-Kommunikation: Alle Steuergeräte noch erreichbar? Keine Timeout-Fehler?
- Live-Daten-Vergleich: Stimmen die Werte mit der Baseline überein (abzüglich der emulierten Parameter)?
- Adaptionswerte zurücksetzen: Gezielt nur die betroffenen Adaptionen
Driving Cycle und OBD-Readiness
- Markenspezifischen Driving Cycle durchführen (Mercedes, BMW und VW haben unterschiedliche Anforderungen)
- OBD-Monitore durchlaufen lassen: Typisch 20–40 Minuten Fahrt unter definierten Bedingungen
- Erneuter Diagnose-Scan: Alle Monitore „ready”? Keine neuen Fehlercodes?
- Langzeit-Adaptionswerte prüfen: Driften die Werte oder stabilisieren sie sich?
Dokumentation und Übergabe
Jede Emulator-Integration wird vollständig dokumentiert:
- Fehlerspeicher vorher/nachher (alle Steuergeräte)
- Live-Daten vorher/nachher (alle relevanten Parameter)
- Adaptionswerte vorher/nachher
- OBD-Readiness-Status
- Verwendeter Emulator-Typ und Konfiguration
- Durchgeführte Driving Cycles
Fazit: Das Netzwerk als Prüfinstanz
Moderne Fahrzeuge sind keine Sammlung isolierter Systeme, sondern ein hochvernetztes Ökosystem, in dem jedes Steuergerät die Arbeit der anderen überwacht. Ein Emulator, der nur einen einzelnen Sensorwert fälscht, wird von diesem Netzwerk in kürzester Zeit identifiziert – durch CAN-Bus-Kreuzreferenzen, zeitliche Korrelationen, Alive-Counter und steuergeräteübergreifende Plausibilitätsprüfungen. Die Konsequenz ist nicht nur ein Fehlercode, sondern eine Kaskade von Folgefehlern, die das Fahrzeug in den Notlauf zwingen kann.
Professionelle Emulator-Integration bedeutet, das gesamte System zu verstehen und zu beherrschen. Bei KFZ Dietrich verfügen wir über XENTRY, ODIS und ISTA – dieselben Diagnosesysteme, die in den Entwicklungsabteilungen und Vertragswerkstätten der Hersteller eingesetzt werden. Damit können wir nicht nur Fehlercodes lesen, sondern die gesamte Signalkette verifizieren: von der Emulator-Ausgabe über den CAN-Bus bis zur Verarbeitung im Steuergerät. Das ist der Unterschied zwischen einer Integration, die funktioniert, und einer, die auf der Rennstrecke zum Stillstand führt.
Hinweis: Alle beschriebenen Maßnahmen betreffen ausschließlich Fahrzeuge im reinen Motorsport-Einsatz. Die Manipulation abgasrelevanter Systeme an Fahrzeugen im öffentlichen Straßenverkehr ist nach §19 StVZO unzulässig.