Emulatoren und CAN-Bus: Professionelle Integration

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:

1. DDE (Motorsteuergerät): Differenzdruck unplausibel bei Last → P244A (Differenzdrucksensor – Signal unplausibel)
2. DDE: Setzt Rußmassen-Berechnung auf Ersatzwert → berechnet unkontrolliert steigende Rußmasse
3. DDE: Leitet Regenerationsversuch ein → Nacheinspritzung aktiv → Kraftstoff im Abgasstrang
4. DDE: Regeneration „erfolglos” (Differenzdruck ändert sich nicht) → Regenerationsfehler P2463
5. DDE: Mehrfache erfolglose Regeneration → Serviceregeneration angefordert → Warnleuchte MIL
6. DDE: Begrenzt Motorleistung (Notlauf Stufe 1) → max. 75 % Drehmoment
7. DDE: CAN-Nachricht „Motormoment reduziert” → EGS (Getriebesteuergerät) empfängt
8. EGS: Passt Schaltprogramm an reduziertes Moment an → härtere Schaltungen, eingeschränkte Gänge
9. DSC (ABS/ESP): Empfängt reduziertes Motor-Soll-Moment → passt ESP-Eingriffsschwellen an
10. 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:

1. ME (Motorsteuergerät): Heizerstrom Sonde 2 = 0 A → P0141 (Sonde 2 Heizkreis)
2. ME: Sonde 2 als defekt markiert → Katalysator-Monitor kann nicht durchgeführt werden
3. ME: OBD-Readiness Catalyst Monitor = „not ready” → MIL nach 2 Driving Cycles
4. ME: Setzt Gemischregelung auf Open Loop (keine Nachkat-Korrektur)
5. ME: Langzeit-Kraftstoffanpassung driftet → LTFT Bank 1 > +15 %
6. ME: LTFT-Grenzwert überschritten → P0170 (Fuel Trim Malfunction)
7. ME: Zusätzlicher Fehler → Motorleistung begrenzt → Notlauf
8. SCR-Steuergerät (falls vorhanden): Empfängt fehlerhafte Lambda-Basis → SCR-Dosierung falsch
9. 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, Abgastemperaturen, DPF-System und AGR-System. Welche Blocknummer welchen Wert trägt, hängt vom Steuergerät ab – ODIS ordnet die Werte im Klartext zu und stellt sie überwiegend als Soll-Ist-Paar dar.

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

1. Vollständiger Fehlerspeicher-Scan: Alle Steuergeräte, nicht nur das Motorsteuergerät
2. CAN-Bus-Kommunikation prüfen: Alle Steuergeräte ansprechbar, keine Timeout-Fehler
3. Live-Daten-Baseline: Aufzeichnung aller emissionsrelevanten Parameter bei verschiedenen Betriebspunkten
4. Adaptionswerte dokumentieren: Alle relevanten Langzeitadaptionen sichern
5. Software-Versionen notieren: Wichtig für die Auswahl des passenden Emulators

Integration und sofortige Verifikation

1. Emulator-Einbau mit korrekter CAN-Bus-Anbindung (falls CAN-aktiver Emulator)
2. Erster Diagnose-Scan: Sofortige Prüfung auf neue Fehlercodes
3. CAN-Bus-Kommunikation: Alle Steuergeräte noch erreichbar? Keine Timeout-Fehler?
4. Live-Daten-Vergleich: Stimmen die Werte mit der Baseline überein (abzüglich der emulierten Parameter)?
5. Adaptionswerte zurücksetzen: Gezielt nur die betroffenen Adaptionen

Driving Cycle und OBD-Readiness

1. Markenspezifischen Driving Cycle durchführen (Mercedes, BMW und VW haben unterschiedliche Anforderungen)
2. OBD-Monitore durchlaufen lassen: Typisch 20–40 Minuten Fahrt unter definierten Bedingungen
3. Erneuter Diagnose-Scan: Alle Monitore „ready”? Keine neuen Fehlercodes?
4. 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.

Nerd-Box: Warum bei der CAN-Bus-Emulation jede Schicht von der nächsten überwacht wird – und eine Prüfung auf der untersten Ebene nicht reicht

Die CAN-Bus-Architektur moderner Fahrzeuge ist ein verschachteltes Schichtenmodell: Die Konsistenz jeder einzelnen Ebene wird von der darüberliegenden Ebene überwacht. Wer auf einer tiefen Ebene einen Wert manipuliert, muss damit rechnen, dass die darüberliegende Ebene die Abweichung bemerkt, lange bevor der Fehler sichtbar wird. Eine Prüfung an einer einzigen Stelle greift zu kurz – belastbar wird eine Emulation erst, wenn sie die steuergeräteübergreifende Plausibilität über mehrere Ebenen hinweg konsistent bedient.

Die physikalische Schicht ist CAN 2.0B nach ISO 11898. Bis hierhin ist die Welt einfach: Differentielle Spannungspegel auf CAN-H und CAN-L, NRZ-Kodierung mit Bit-Stuffing, Arbitration über den Identifier, Hardware-CRC über jeden Frame. Ein Emulator, der nur diese Schicht bespielt, arbeitet auf der untersten Ebene – er kann Frames senden und empfangen, aber er sieht die Kontrollstrukturen der Ebenen darüber nicht.

Die Transport-Schicht ist ISO 15765-2 (ISO-TP). Hier werden längere Payloads über mehrere CAN-Frames segmentiert, mit FlowControl-Frames und STmin-Timing. Ein Emulator, der UDS-Nachrichten fälscht, muss die Segmentierung korrekt umsetzen – sonst lehnt der empfangende Stack die Nachricht ab, noch bevor die Anwendungsschicht sie sieht.

Die Anwendungs-Schicht ist AUTOSAR COM mit herstellerspezifischen Sicherungen. Das ist die Ebene, auf der moderne Fahrzeuge die eigentliche Prüfung durchführen. AUTOSAR COM-Signale enthalten:

• Alive-Counter (AUTOSAR E2E): Ein Zähler, der mit jeder Nachricht inkrementiert – in E2E Profile 2 vier Bit breit, in Profile 5 acht Bit. Der empfangende Stack prüft Sprünge – ein Sprung um 2 bedeutet verlorene Nachricht, ein Sprung um 0 bedeutet doppelte Nachricht, ein Rücksprung bedeutet Manipulation. E2E Profile 5 nutzt zusätzlich eine 16-Bit-CRC mit Data-ID-Einstreuung, die ohne Kenntnis des Algorithmus nicht reproduzierbar ist.
• Data-ID-Feld: Jedes geschützte Signal hat eine eigene Data-ID, die in die CRC einfließt. Kopiert ein Emulator ein Signal aus einem anderen Frame, passt die Data-ID nicht, die CRC ist falsch, der empfangende Stack verwirft die Nachricht.
• Timeout-Supervision: Jedes Signal hat eine erwartete Wiederholrate (typisch 10–100 ms). Bleibt die Nachricht aus, setzt das empfangende Steuergerät nach 3–5 Zyklen einen Timeout-Fehler und geht auf Ersatzwert über. Der Notlauf ist damit programmiert.

Die Funktions-Schicht ist die Plausibilitätsprüfung über Modellgleichungen. Und hier beginnt das eigentliche Problem der schichtenübergreifenden Prüfung. Das Motorsteuergerät berechnet aus der Einspritzmenge, der Luftmasse, der Kühlmitteltemperatur, der Fahrzeuggeschwindigkeit vom ABS-Steuergerät und dem Drehmomentanforderung vom Getriebesteuergerät einen erwarteten Lambda-Wert. Weicht die gemessene Lambda um mehr als einen definierten Toleranzkorridor ab, und besteht die Abweichung länger als eine definierte Mindestdauer, setzt das Steuergerät einen Plausibilitätsfehler – typisch generische Codes wie P2096/P2097 (Gemischregelung nach Kat) oder P0170/P0173 (Kraftstoff-Trim Bank 1/2), bei BMW zusätzlich ein herstellerspezifischer Code aus dem DME.

Ein Emulator, der nur den Lambda-Rohwert auf dem Bus fälscht, bedient die untere Ebene korrekt. Aber die nächsthöhere Ebene – das ESP-Steuergerät – empfängt den reduzierten Motor-Soll-Momenten-Wert, den das Motorsteuergerät sendet, sobald es in Gemischregelung Open Loop wechselt. Das ESP wundert sich, warum das Motor-Soll-Moment zum Fahrpedal-Winkel nicht passt, und setzt seinerseits einen Fehler. Die oberste Ebene – das Kombiinstrument – empfängt MIL-Anforderung und Leistungsreduzierung gleichzeitig und meldet dem Fahrer „Motorstörung Werkstatt aufsuchen”. Die Manipulation ist aufgeflogen, bevor sie überhaupt Wirkung zeigen konnte.

Wo XENTRY/ODIS/ISTA den Unterschied machen: Diese Tools öffnen die UDS-ExtendedDiagnosticSession auf jedem beteiligten Steuergerät gleichzeitig und lesen die internen Plausibilitäts-Zwischenwerte über Service $22 ReadDataByIdentifier. Bei Mercedes XENTRY sind das Größen wie der modellierte Lambda-Sollwert, die Abweichung zwischen Messwert und Modell sowie Kurzzeit-Integrator und Langzeit-Adaptionswert – ihre Kennungen sind herstellerspezifisch und nur über die XENTRY-Datenbasis im Klartext zu lesen. Bei BMW ISTA liest man die „Prüfstatus”-Matrix aus dem DME, die für jeden Plausibilitätsmonitor den aktuellen Zähler und die Enabling Conditions zeigt. Bei VW ODIS sind es die Messwerteblöcke der Gemischregelung mit Soll-Ist-Vergleich. Ohne diese Sicht auf die Modellgleichungen arbeitet ein Integrator blind – er sieht den DTC, aber nicht die Ebene, auf der die Plausibilitätsprüfung angesprochen hat.

Daraus folgt die zentrale Regel: Ein Emulator, der einen realen Sensor-Wert aus einer Referenzmessung abspielt, wird in exakt dem Moment scheitern, in dem der Betriebspunkt des Fahrzeugs von der Referenzmessung abweicht – Motorlast ändert sich, Drehzahl springt, Außentemperatur fällt. Professionelle CAN-Integration bedeutet, das Modell selbst zu emulieren, nicht einzelne Messwerte – und das geht nur, wenn man das Modell aus der Herstellerdiagnose kennt. Denn die Kontrolle wird immer von der übergeordneten Ebene ausgeübt, nicht von der untersten.

---

Weiterführende Informationen

• Spezialisierte Fahrzeugdiagnose & Instandsetzung
• Steuergerät-Service
• ND-Tuning
• CAN-Bus-Diagnose
• Alle Reparatur-Leistungen im Überblick
• VW/Audi-Diagnose
• Mercedes-Diagnose

Haben Sie technische Fragen zu Ihrem Fahrzeug? Schreiben Sie unserer Werkstatt direkt über die Warteliste für eine fachliche Ersteinschätzung.

---

Das könnte Sie auch interessieren

• AGR/EGR-Emulator: Abgasrückführung im Motorsport stoppen
• Katalysator-Emulator: Integration für Track-Fahrzeuge
• Motorswap: Steuergeräte-Integration bei Umbau