Warum die Rohdaten-Analyse für das Smart Roadster Tuning entscheidend ist
Wer ECU-Kennfelder in einer Hex-Binärdatei ohne DAMOS-Datei sucht, betritt eine der anspruchsvollsten – aber auch lohnendsten – Disziplinen im Motorsteuergeräte-Tuning. Eine DAMOS- (oder A2L-)Definitionsdatei liefert ein vollständiges Kennfeldverzeichnis, beschriftet und bearbeitungsbereit. Ohne sie starrt man auf zehntausende Byte roher Hexadezimalwerte ohne jede Orientierung. Beim Smart Roadster 452 und seinem Bosch MEG 1.1 Steuergerät sind vollständige DAMOS-Dateien in der Öffentlichkeit kaum verfügbar. Wer dieses Fahrzeug von Grund auf tunen möchte, muss daher verstehen, wie man Kennfelder manuell findet, identifiziert und validiert. Dieser Leitfaden zeigt den systematischen Ansatz, den Profis verwenden: von der Erkennung von Datenstrukturen bis zur Querprüfung mit physikalischem Verhalten. Vorkenntnisse in Assembler sind nicht erforderlich, aber Geduld und eine methodische Denkweise sind unerlässlich.
Die Binärlandschaft verstehen, bevor man sucht
Bevor man nach Kennfeldern sucht, muss man verstehen, was eine Firmware-Binärdatei tatsächlich enthält. Das MEG 1.1 Flash-Image ist typischerweise 512 KB groß. Dieser Speicher wird aufgeteilt zwischen ausführbarem Code (Routinen, die der Prozessor ausführt), konstanten Daten (feste Werte wie Sensorkalibrierungen) und Lookup-Tabellen – den Kennfeldern und Kennlinien, die man bearbeiten möchte. Code-Bereiche sind dicht, unregelmäßig und enthalten viele kurze, wiederkehrende Bytesequenzen, die typisch für kompiliertes C oder Assembler sind. Kennfeldbereiche hingegen sind strukturiert, monoton und regelmäßig.
Öffne deine Binärdatei in einem Hex-Editor oder in WinOLS. Wer neu in diesem Tool ist, findet in dieser Einsteiger-Anleitung zum Öffnen einer Smart Roadster Binärdatei in WinOLS eine gute Orientierung, bevor man sich in die manuelle Kennfeldsuche stürzt. In WinOLS schalte in die 8-Bit- oder 16-Bit-Kennfeldansicht und scrolle durch die Datei. Das Auge lernt schnell, flache Code-Abschnitte von den sanften Verläufen und Wiederholungsmustern zu unterscheiden, die Kalibrierdaten kennzeichnen.
Bytereihenfolge und Datenbreite
Das MEG 1.1 verwendet eine vom Motorola HC12 abgeleitete Architektur mit Big-Endian-Bytereihenfolge. 16-Bit-Werte werden mit dem höherwertigen Byte zuerst gespeichert. Liest man einen 16-Bit-Wert bei Offset 0x1A00, ergibt sich der Wert als (byte[0x1A00] << 8) | byte[0x1A01]. Die falsche Bytereihenfolge ist einer der häufigsten Fehler bei Einsteigern – eine im Little-Endian-Format gelesene Ladedruck-Kennlinie ergibt Unsinn, während dieselben Daten im Big-Endian-Format eine saubere Druckkurve ergeben. Die Bytereihenfolge sollte immer frühzeitig anhand eines bekannten Referenzwerts bestätigt werden (z. B. der Drehzahlbegrenzer, typischerweise bei etwa 7.200 U/min, kodiert als 0x1C20), um zu prüfen, welche Bytereihenfolge einen physikalisch plausiblen Wert liefert.
Mustererkennung: Die Kerntechnik zum Auffinden von ECU-Kennfeldern in Hex-Binärdateien
Die praktische Methode zum Auffinden von Kennfeldern ohne DAMOS basiert auf der Erkennung der Signaturen, die Kalibriertabellen in rohen Binärdaten hinterlassen.
Achsentabellen und monotone Sequenzen
Achsen – die Drehzahl- oder Lastpunkte, die ein Kennfeld indizieren – sind fast immer monoton steigende Sequenzen. Eine Drehzahlachse könnte lauten: 800, 1200, 1600, 2000, 2400, 3000, 3600, 4200, 5000, 6000, 7200 U/min. In 16-Bit-Big-Endian-Hex ergibt das: 03 20, 04 B0, 06 40, 07 D0, 09 60, 0B B8, 0E 10, 10 68, 13 88, 17 70, 1C 20. Man sucht in der Binärdatei nach Sequenzen von 16-Bit-Wörtern, die um annähernd gleiche oder physikalisch plausible Schritte ansteigen. Achsentabellen sind beim MEG 1.1 in der Regel 8 bis 16 Einträge lang. Hat man eine Achse gefunden, befinden sich die von ihr indizierten Kennfelddaten fast immer unmittelbar danach im Speicher oder werden durch eine nahe gelegene Zeigertabelle referenziert.
Heuristik zur Kennfeldform
Zweidimensionale Kennfelder (Achse × Achse × Wert) sind beim MEG 1.1 typischerweise 8×8, 12×8 oder 16×8 groß. Ladedruckkennfelder, Zündwinkelkennfelder und Anfettungskennfelder folgen alle diesem Muster. In WinOLS offenbart sich ein echtes Kennfeld als glatte Fläche, sobald man einen Bereich auswählt und die korrekte Breite zuweist – mit Spitzen in der Ecke hoher Drehzahl und hoher Last, Tälern im Leerlauf. Ein zufälliger Code-Bereich mit denselben Abmessungen sieht dagegen wie chaotisches Rauschen aus. Der Vergleich der Ladedruckkennfeldwerte zwischen den Varianten 45 kW, 60 kW, 66 kW und 74 kW ist eine zuverlässige Methode zur Quervalidierung einer vermuteten Ladedrucktabelle: Die Werte müssen physikalisch mit den bekannten Ladedrücken der jeweiligen Variante übereinstimmen.
Prüfsummen-Markierungswerte
Die MEG 1.1 Firmware enthält Prüfsummenblöcke, die Kalibrierbereiche schützen. Diese erscheinen als Paare von 32-Bit-Wörtern an festen Offsets – die gespeicherte Prüfsumme und ihr Komplement. Das Erkennen dieser Markierungen ist wertvoll, da sie den Kalibrierbereich eingrenzen und den Suchraum erheblich einschränken. Das Verständnis dieser Blöcke ist auch deshalb entscheidend, weil jede Änderung an Kalibrierdaten ohne Aktualisierung der Prüfsumme dazu führt, dass das Steuergerät den Flash ablehnt – wie im Detail im Artikel über die Notwendigkeit der Prüfsummenkorrektur vor dem Schreiben einer modifizierten Binärdatei erläutert wird.
Werkzeuge und Arbeitsablauf für die manuelle Kennfeldsuche
Mehrere Werkzeuge beschleunigen den Prozess, sobald man die grundlegenden Prinzipien versteht.
WinOLS Kennfeldsuche
WinOLS enthält eine integrierte Kennfeldsuchfunktion, die Bereiche der Binärdatei nach ihrer Ähnlichkeit mit typischen Kennfeldformen bewertet. Die Suchparameter werden auf 16-Bit-Big-Endian, Breite 8 oder 12 gesetzt, und das Tool bewertet jede mögliche Tabellenanfangsadresse. Die Ergebnisse werden nach einem Glattheitswert sortiert. Das ist nicht unfehlbar – glatte Code-Bereiche können hohe Werte erhalten –, aber es eliminiert sofort etwa 80 % des Suchraums und hinterlässt eine überschaubare Liste von Kandidaten zur manuellen Auswertung.
Hex-Editoren mit Skriptunterstützung
Tools wie der 010 Editor unterstützen binäre Vorlagen und Skripte. Man kann ein kurzes Skript schreiben, das die Binärdatei nach monoton steigenden 16-Bit-Sequenzen der Länge 8–16 durchsucht und deren Offsets ausgibt. Das automatisiert die Achsensuche und ist besonders effektiv beim Vergleich zweier Binärdateien aus verschiedenen Firmware-Versionen – echte Kalibrierdaten verschieben sich zwischen Versionen vorhersehbar, während Code sich stärker umstrukturiert. Die Binärvorlagensprache des 010 Editors ist gut dokumentiert, und die Community hat generische Automotive-ECU-Vorlagen veröffentlicht, die für das MEG 1.1 angepasst werden können.
Differenzialanalyse zwischen Varianten
Eine der leistungsfähigsten Techniken für den Smart Roadster ist das Binary-Diffing – der Vergleich zweier Steuergeräte-Images, die sich nachweislich nur in einem Kalibrierbereich unterscheiden. Zum Beispiel teilen sich ein 60-kW- und ein 66-kW-SB2-Binary dieselbe Basis-Firmware, unterscheiden sich aber in den Ladedruck-, Gemisch- und Zündwinkelkalibrierungen. Beide in WinOLS laden und die Versionsvergleichsfunktion verwenden hebt genau hervor, welche Bytes sich geändert haben. Diese geänderten Bereiche sind per Definition Kalibrierdaten und kein ausführbarer Code. So hat die Community die MEG 1.1 Kalibrierstruktur zuerst kartiert, und es bleibt der zuverlässigste Ausgangspunkt für jeden, der noch nie mit diesem Steuergerät gearbeitet hat. Wer neugierig ist, was eine echte DAMOS-Datei kostenlos liefern würde, findet im Artikel über was eine DAMOS-Datei enthält und wie sie den Tuning-Workflow verändert eine Einordnung dieses manuellen Aufwands.
Kennfelder validieren, wenn man glaubt, sie gefunden zu haben
Eine plausibel aussehende Tabelle zu finden ist nur die halbe Arbeit. Man muss sie validieren, bevor man ihr den Motor anvertraut.
Physikalische Plausibilitätsprüfungen
Jeder Kennfeldwert muss technisch sinnvoll sein. Ein Zündwinkelkennfeld sollte bei Teillast und mittlerer Drehzahl maximale Frühzündung aufweisen (etwa 28–32° v. OT) und unter hohem Ladedruck zur Klopfvermeidung zurückgenommen werden. Ein Ladedruckzielkennfeld sollte Werte zeigen, die mit den bekannten Hardwaregrenzen des Garrett 1238S Turboladers übereinstimmen – grob 0,89 bar für die 45-kW-Variante, bis hin zu 1,43 bar für den vollen Brabus. Werte außerhalb dieser Bereiche deuten entweder auf einen Skalierungsfehler oder auf eine falsch identifizierte Tabelle hin. Boschs technische Dokumentation zur Motormanagement-Sensorkalibrierung ist eine nützliche Referenz, um zu prüfen, ob eine vermutete Sensortabelle physikalisch plausible Skalierungswerte aufweist.
Querprüfung mit Live-Daten
Die endgültige Validierungsmethode besteht darin, eine kleine, konservative Änderung an der vermuteten Kennfeld vorzunehmen, die modifizierte Binärdatei aufzuspielen und die Reaktion des Motors über Live-OBD-Daten zu beobachten. Wer glaubt, das Ladedruckzielkennfeld gefunden zu haben, erhöht eine Zelle im mittleren Drehzahlbereich um 50 mbar und prüft, ob der gemessene Ladedruck an diesem Drehzahl- und Lastpunkt um annähernd denselben Betrag steigt. Diese geschlossene Validierungsschleife bestätigt gleichzeitig die Kennfeldidentität und den Skalierungsfaktor. Sie erfordert eine zuverlässige OBD-Schnittstelle und ein Steuergerät, das den Flash akzeptiert – beides Grundvoraussetzungen für jede ernsthafte Tuningarbeit.
Community-Wissen als Plausibilitätsprüfung
Die Smart Roadster Community hat erhebliches kollektives Wissen über MEG 1.1 Kennfeldpositionen angesammelt. Forumsbeiträge auf Smart Car of America Forums und in der europäischen Smart-Enthusiasten-Community enthalten partielle Kennfeld-Offset-Tabellen, die von Tunern beigetragen wurden, die diese Arbeit über viele Jahre geleistet haben. Community-Offsets sollten als Ausgangshypothese behandelt werden, nicht als Evangelium – Firmware-Versionsunterschiede bedeuten, dass ein für Version 1037371568 korrekter Offset in einer früheren Revision um einige Bytes abweichen kann. Immer gegen die eigene spezifische Binärdatei verifizieren.
Häufige Fehler bei der Kennfeldsuche in rohen Binärdateien
Selbst erfahrene Tuner machen diese Fehler, wenn sie ohne DAMOS an einem unbekannten Steuergerät arbeiten.
- Code-Konstanten mit Kalibrierdaten verwechseln. Kompilierter C-Code enthält viele feste Zahlenwerte, die auf den ersten Blick wie Kennfelder aussehen. Wenn ein Bereich nicht physikalisch vorhersehbar auf Änderungen reagiert, handelt es sich wahrscheinlich um Code.
- Skalierungsfaktoren ignorieren. Eine Ladedrucktabelle kann Werte in Einheiten von 10 mbar oder als Prozentsatz einer internen Referenz speichern. Ein physikalisch unplausibler Bereich deutet fast immer auf ein Skalierungsmissverständnis hin, nicht auf eine falsche Tabelle.
- Ohne Prüfsummenkorrektur editieren. Das MEG 1.1 verweigert den Start von einer Binärdatei mit falscher Prüfsumme. Jede Editiersitzung muss mit einer Prüfsummenaktualisierung enden – keine Ausnahmen.
- Kennfeldabmessungen nur aus der visuellen Inspektion ableiten. Eine 16×4-Tabelle sieht sehr anders aus als eine 8×8-Tabelle mit denselben Daten. Immer mehrere Breitenhypothesen testen, bevor man die korrekte Struktur festlegt.
- Mit einem fehlerhaften Auslesevorgang arbeiten. Ein einzelner Byte-Lesefehler im ursprünglichen Binär-Dump vergiftet jede daraus abgeleitete Analyse. Den Flash-Auslesevorgang immer gegen einen zweiten Auslesevorgang verifizieren, bevor man mit der Analyse beginnt.
Alles zusammenführen: Ein praktischer Einstiegs-Workflow
Um ECU-Kennfelder in einer Hex-Binärdatei am Smart Roadster MEG 1.1 zu finden, empfiehlt sich diese Vorgehensweise. Erstens: zwei oder mehr bekannte Binärdateien verschiedener Leistungsvarianten beschaffen und per Diff die Grenzen des Kalibrierbereichs ermitteln. Zweitens: Innerhalb dieser Grenzen die WinOLS-Kennfeldsuche mit 16-Bit-Big-Endian-Einstellungen ausführen und die bestbewerteten Kandidaten prüfen. Drittens: Achsentabellen identifizieren, indem man nach monoton steigenden 16-Bit-Sequenzen mit physikalisch plausiblen Werten (Drehzahl, Last, Temperatur) sucht. Viertens: Das 2D-Kennfeld rekonstruieren, indem man den Datenblock unmittelbar nach den Achsen liest und mehrere Breitenhypothesen testet, bis eine glatte Fläche erscheint. Fünftens: Die Skalierung durch Querprüfung bekannter Werte validieren – beispielsweise sollte der Leerlauf-Zündwinkel nahe an den in Smarts Werkstattdokumentation veröffentlichten Werten liegen. Sechstens: Eine minimale Teständerung vornehmen, Prüfsummen aktualisieren und aufspielen, um zu validieren. Siebtens: Ergebnisse mit Offsets, Abmessungen und Skalierungsfaktoren dokumentieren, damit der nächste Tuner von der Arbeit profitiert. Beim ersten Mal ist das langsam. Beim fünften Kennfeld wird es fast intuitiv.
Die Fähigkeit zu beherrschen, ECU-Kennfelder in einer Hex-Binärdatei ohne DAMOS zu finden, unterscheidet einen echten ECU-Tuner von jemandem, der lediglich vorgefertigte Dateien aufspielt. Für den Smart Roadster 452, bei dem werksseitige Kalibrierdaten selten sind und die Belohnungen eines gut ausgeführten Remaps erheblich sind, ist diese Kompetenz besonders wertvoll. Das MEG 1.1 ist ein gut strukturiertes Steuergerät, und mit den oben beschriebenen Techniken – Differenzialanalyse, Mustererkennung, physikalische Plausibilitätsprüfungen und geschlossene Validierungsschleifen – wird seine Kalibrierungslandschaft navigierbar. Nimm dir Zeit, dokumentiere alles und spiele niemals eine unvalidierte Binärdatei auf ein Fahrzeug auf, das dir wichtig ist.
