Zwei Dateien können zusammengehören und trotzdem der falsche Vergleich sein
Eine Originaldatei mit einer modifizierten Datei zu vergleichen klingt einfach: beide öffnen, Unterschiede finden und die geänderten Maps prüfen. Die Schwierigkeit beginnt, wenn die Dateien nicht auf derselben Softwarebasis beruhen.
Ein OEM-Update kann Daten verschieben, Codebereiche ersetzen, Kalibrierungsstrukturen ändern oder neue Map-Varianten einführen. Ein virtueller Read kann aus einer passenden Datenbankdatei stammen und nicht aus exakt den Bytes, die zuvor im ECU gespeichert waren. Eine Kundendatei kann bereits nicht dokumentierte Änderungen enthalten.
WinOLS kann Unterschiede anzeigen, Projekte verbinden und die Übernahme von Änderungen unterstützen, aber die Software ersetzt keine Dateianalyse und kein technisches Urteilsvermögen. Vor dem Import muss der Tuner klären, was jede Datei ist und ob der Vergleich gültig ist.
Dateien vor dem Vergleich eindeutig definieren
Verwende im Projekt klare Begriffe:
- ORI: die verifizierte Originaldatei oder die bestmögliche Basis für genau diese ECU-Software.
- MOD: eine modifizierte Version, die auf einer dokumentierten Basis beruht.
- OEM-Update: eine spätere oder andere Softwareversion des Herstellers.
- Virtuelles Original: eine Originaldatei, die der Tool-Anbieter anhand der ECU-Identifikation zugeordnet hat.
- Readback: Daten, die nach einem Write physisch aus dem Steuergerät gelesen wurden, sofern unterstützt.
- Unbekannte Datei: jede Datei, für die nicht genug Belege für eine sichere Einordnung vorliegen.
Eine Datei nicht allein deshalb als ORI bezeichnen, weil im Namen „original“ steht. Dateinamen sind Hinweise, kein Beweis.
Ein Datei-Identifikationsblatt anlegen
Vor dem Öffnen der Vergleichsansicht alle verfügbaren Identifikationsdaten jeder Datei erfassen.
| Identifikationsfeld | Datei A | Datei B |
|---|---|---|
| ECU-Familie | Exakten Typ notieren | Exakten Typ notieren |
| Hardware-Nummer | Wert aus Tool oder Aufkleber | Wert aus Tool oder Quelle |
| Software-Nummer | Exakter Wert | Exakter Wert |
| Kalibrierungs- oder Update-Nummer | Falls vorhanden | Falls vorhanden |
| Leseverfahren | OBD, Bench, Boot oder virtuell | OBD, Bench, Boot oder virtuell |
| Dateigröße | In Bytes erfasst | In Bytes erfasst |
| Quelle | Fahrzeug, Tool-Datenbank oder Kunde | Fahrzeug, Tool-Datenbank oder Kunde |
| Bekannte Historie | Serie, getunt, aktualisiert oder unbekannt | Serie, getunt, aktualisiert oder unbekannt |
Eine übereinstimmende Dateigröße ist hilfreich, beweist aber nicht, dass zwei Dateien dieselbe Softwarestruktur haben.
Drei verschiedene Vergleichsaufgaben
Die meisten WinOLS-Vergleiche fallen in eine von drei Situationen. Jede erfordert ein anderes Maß an Vorsicht.
1. ORI gegen MOD auf derselben Basis
Das ist der sauberste Vergleich. Der MOD wurde direkt aus der ORI erstellt und beide Dateien haben die gleiche Struktur. Unterschiede sollten den dokumentierten Kalibrierungsänderungen und den erwartbaren prüfsummenbezogenen Änderungen entsprechen.
2. Eine OEM-Softwareversion gegen eine andere
Das ist kein normaler Tuning-Vergleich. Große Bereiche können unterschiedlich sein, weil der Hersteller Code, Diagnose, Kalibrierungsstruktur oder Datenausrichtung geändert hat. Unterschiede dürfen nicht als Tuning-Änderungen interpretiert werden.
3. Eine modifizierte alte Version gegen eine neuere OEM-Version
Das ist das Transfer-Szenario mit dem höchsten Risiko. Die alten Adressen zeigen möglicherweise nicht mehr auf dieselben Maps. Änderungen müssen gegen die neue Softwarestruktur neu aufgebaut und validiert werden, statt sie blind zu kopieren.
Mit einer groben Differenzanalyse beginnen
Bevor einzelne Maps geöffnet werden, das allgemeine Muster der Unterschiede betrachten.
Fragen:
- Konzentrieren sich die Änderungen auf einen kleinen Kalibrierungsbereich?
- Verteilen sich die Unterschiede über fast die gesamte Datei?
- Wirken große Blöcke verschoben?
- Unterscheiden sich Code- und Kalibrierungsbereiche gleichermaßen?
- Gibt es wiederkehrende Differenzmuster?
- Enthält eine Datei zusätzliche Daten oder Padding?
- Passen die Änderungen zur Dateihistorie?
Eine kompakte Gruppe von Map-Änderungen kann zu einer normalen Kalibrierungsbearbeitung passen. Große, weit verbreitete Unterschiede erfordern meist eine Analyse der Softwareversion, bevor auf Map-Ebene Schlüsse gezogen werden.
Differenzmuster sind Hinweise, kein Beweis
| Differenzmuster | Mögliche Erklärung | Erforderliche Prüfung |
|---|---|---|
| Kleine Cluster innerhalb bekannter Maps | Dokumentierte Kalibrierungsänderungen | Achsen, Einheiten und erwartete Funktion bestätigen |
| Große zusammenhängende Bereiche | OEM-Softwareupdate oder andere Dateibasis | Softwarenummern und Code-Struktur prüfen |
| Wiederholte einzelne Bytes | Prüfsumme, Zähler, Metadaten oder Tool-Verarbeitung | Protokoll und Prüfsummen-Workflow prüfen |
| Ähnliche Maps an anderen Adressen | Datenverlagerung zwischen Softwareversionen | Nach Struktur, Achsen und Funktion abgleichen, nicht nach Adresse |
| Unterschiede außerhalb erwarteter Kalibrierungsbereiche | Falsche Datei, Update, Patch oder nicht dokumentierte Modifikation | Transfer stoppen, bis die Herkunft der Datei verstanden ist |
Kein Muster sollte als Garantie behandelt werden. Es dient dazu, festzulegen, was genauer geprüft werden muss.
Maps vergleichen, nicht nur Adressen
Eine Adresse ist nur innerhalb ihrer eigenen Softwarestruktur gültig. Wenn Dateien unterschiedliche Softwareversionen verwenden, kann dieselbe Funktion an einer anderen Adresse gespeichert oder anders dargestellt sein.
Für jede verglichene Map bestätigen:
- Map-Dimensionen;
- Achsenwerte;
- Achsenreihenfolge;
- Datentyp;
- Byte-Reihenfolge;
- Faktor und Offset;
- technische Einheit;
- umgebende Datenstruktur;
- Zusammenhang mit zugehörigen Ziel- und Limiter-Maps.
Eine Tabelle mit derselben Form ist nicht automatisch dieselbe Funktion. Auch Achsen und umliegende Logik müssen plausibel sein.
Referenzversionen mit Bedacht nutzen
Eine Referenzversion ist nützlich, wenn dieselbe Projektbasis geprüft wird oder wenn ein kontrollierter Update-Vergleich durchgeführt wird. So kann der Techniker Werte und Unterschiede prüfen, ohne ständig zwischen Dateien zu wechseln.
Ein sauberer Workflow ist:
- Die verifizierte Originalversion unverändert lassen.
- Die Vergleichsdatei als separate Version oder verknüpftes Projekt erstellen oder importieren.
- Vor dem Verbinden der Dateien die Projektidentifikation bestätigen.
- Zuerst die groben Unterschiede prüfen.
- Bekannte Maps öffnen und Struktur sowie Werte vergleichen.
- Festhalten, welche Änderungen bestätigt, unsicher oder verworfen sind.
Änderungen nicht automatisch übertragen, nur weil WinOLS ähnliche Bereiche erkennt.
Wann ein automatischer Import sinnvoll ist
Das Importieren von Änderungen ist am zuverlässigsten, wenn die Dateien dieselbe Softwarebasis teilen und die Beziehung von Original zu Modifikation dokumentiert ist.
Ein automatischer oder teilautomatischer Transfer sollte mit Vorsicht behandelt werden, wenn:
- die Softwarenummern abweichen;
- eine Datei ein OEM-Update ist;
- eine Datei ein virtueller Read und die andere ein physischer Read ist;
- Map-Adressen verschoben wurden;
- die MOD-Quelldatei undokumentierte Patches enthält;
- Dateigrößen oder Speicherlayouts abweichen;
- das Quellprojekt nicht verifizierte Definitionen verwendet.
In diesen Fällen die erforderlichen Kalibrierungsänderungen Map für Map neu aufbauen und die Logik auf der Zielsoftware prüfen.
Ein Arbeitsblatt für die Übernahme von Änderungen anlegen
| Map oder Funktion | Status der Quelle | Treffer im Ziel | Aktion |
|---|---|---|---|
| Fahrerwunsch | In Quelle bestätigt | Achsen und Einheiten abgeglichen | Neu aufbauen und prüfen |
| Drehmomentbegrenzer | Bestätigt | Mehrere Zielvarianten gefunden | Vor der Bearbeitung untersuchen |
| Ladedruckziel | In Quelle geändert | Skalierung nicht bestätigt | Noch nicht übertragen |
| Unbekannter Patch | Nicht dokumentiert | Kein verifizierter Zielwert vorhanden | Vom Transfer ausschließen |
Dieses Arbeitsblatt verhindert, dass nicht dokumentierte Änderungen aus der Quelle unbemerkt in das neue Projekt gelangen.
Prozentuale Änderungen nicht blind übertragen
Ein häufiger Schnellschuss ist, zu berechnen, wie stark sich ein Wert im alten MOD verändert hat, und denselben Prozentsatz auf eine ähnlich aussehende Map in der neuen Software anzuwenden. Das kann täuschen, weil der Hersteller Basiswert, Einheiten, Limiter-Beziehung oder Regelstrategie geändert haben kann.
Stattdessen fragen:
- Welches Ergebnis sollte die ursprüngliche Änderung erzielen?
- Enthält die neue Software bereits ein überarbeitetes Ziel?
- Welche zugehörigen Maps steuern dieselbe Funktion?
- Sind Achsen und Betriebsbereiche gleichwertig?
- Lässt sich das gewünschte Ergebnis mit Logs validieren?
Das Kalibrierungsziel übertragen, nicht nur die alten Zahlen.
Kalibrierungsänderungen von Patches und Metadaten trennen
Nicht jeder Unterschied ist eine Map-Bearbeitung. Dateien können sich auch unterscheiden durch:
- Prüfsummen-Korrektur;
- tool-spezifische Verarbeitung;
- Programmierzähler;
- Software-Patches;
- Versionsmetadaten;
- Diagnosekonfiguration;
- nicht dokumentierter Vorarbeit.
Unbekannte Änderungen außerhalb des dokumentierten Kalibrierungsbereichs sollten untersucht werden, bevor die Datei freigegeben wird.
Das Zielprojekt nach dem Transfer validieren
Nach dem Neuerstellen oder Importieren von Änderungen eine vollständige Projektprüfung durchführen:
- jede bearbeitete Map gegen ihre Achsen prüfen;
- zugehörige Ziele und Limiter kontrollieren;
- Einheiten und Skalierung bestätigen;
- Interpolation und Randzellen prüfen;
- sicherstellen, dass keine unbeabsichtigten Bereiche verändert wurden;
- die Verantwortlichkeit für die Prüfsumme bestätigen;
- einen Differenzbericht gegen die Ziel-ORI speichern;
- die endgültige Dateiversion klar kennzeichnen;
- die passende Recovery-Datei vorbereiten;
- einen kontrollierten Diagnose- und Datalogging-Test planen.
Ein erfolgreicher Export beweist nicht, dass die Kalibrierungslogik korrekt ist.
Verwandte WinOLS-Ressourcen
Für Definition-Abgleich, Map-Pack-Validierung und Skalierungsprüfungen siehe WinOLS A2L/DAMOS & Map Packs. Vor dem Schreiben der fertigen Datei auch WinOLS-Prüfsummen prüfen.
Für Diskussionen zu ECU-Softwareversionen und reale Dateifälle siehe CarTechnology oder MHHAuto. Forum-Informationen als Recherche nutzen und jede Änderung im tatsächlichen Zielprojekt bestätigen.
Datei-Vergleichs-Checkliste
- Jede Datei als ORI, MOD, OEM-Update, virtuelles Original oder unbekannt einordnen.
- ECU-Hardware und Software-Identifikation erfassen.
- Leseverfahren und Dateigröße bestätigen.
- Prüfen, ob die Dateien dieselbe Softwarebasis teilen.
- Das allgemeine Differenzmuster vor dem Öffnen der Maps prüfen.
- Maps nach Struktur, Achsen, Einheiten und Funktion abgleichen.
- Änderungen nicht allein nach Adresse übertragen.
- Nicht dokumentierte Patches verwerfen, bis sie verstanden sind.
- Änderungen sorgfältig neu aufbauen, wenn das Ziel eine andere OEM-Version ist.
- Einen finalen Differenzbericht gegen das Ziel-Original speichern.
- Prüfsummenbehandlung validieren und Recovery vorbereiten.
FAQ
Kann ich Maps aus einer älteren OEM-Softwareversion in eine neuere kopieren?
Nicht sicher allein nach Adresse. Die Map-Funktion, Dimensionen, Achsen, Skalierung und die umgebende Strategie in der neueren Software bestätigen und dann die beabsichtigte Änderung neu aufbauen.
Bedeutet gleiche Dateigröße, dass die Dateien kompatibel sind?
Nein. Dateien mit derselben Größe können unterschiedlichen Code, unterschiedliche Kalibrierungs-Layouts oder verschiedene Softwareversionen enthalten.
Was ist der sicherste ORI-gegen-MOD-Vergleich?
Der sicherste Vergleich nutzt eine verifizierte Originaldatei und eine dokumentierte modifizierte Version, die direkt aus derselben Originalbasis erstellt wurde.
Warum gibt es Unterschiede außerhalb der Maps, die ich bearbeitet habe?
Das können Prüfsummenänderungen, Metadaten, Tool-Verarbeitung, Zähler oder nicht dokumentierte Arbeiten sein. Vor der Freigabe der Datei identifizieren.
Sollte ein automatischer Import bei einem OEM-Update verwendet werden?
Nur mit sorgfältiger Validierung. Wenn sich die Softwarebasis ändert, können sich Maps verschieben oder ihre Struktur ändern. Manuelle Prüfung und kontrolliertes Neuerstellen sind oft sicherer.
Der WinOLS-Vergleich ist nicht einfach eine Suche nach anderen Bytes. Er ist ein Prozess, bei dem die Dateiidentität bewiesen, der Softwarezusammenhang verstanden und nur die Kalibrierungsentscheidungen übertragen werden, die in der Zielversion weiterhin gültig sind.
