So prüft EcuPrime eine bearbeitete Datei vor der Lieferung

Eine bearbeitete ECU-Datei unterscheidet sich vom Original in einigen tausend Bytes von mehreren Millionen. Diese Bytes zu erzeugen ist der sichtbare Teil der Arbeit. Weniger sichtbar ist der Teil, der entscheidet, ob eine Datei die Software überhaupt verlassen sollte: Was geschieht, wenn Ihre Datei nicht genau die Datei ist, aus der die Lösung gelernt wurde? Dieser Beitrag geht die Prüfungen durch, die EcuPrime zwischen Upload und Download ausführt, auf dem Stand der Software vom 9. Oktober 2026, mit den Zahlen, die wir an diesem Tag gemessen haben, und den Grenzen, die wir kennen.

Schritt 1: Das Steuergerät wird aus der Datei erkannt

Nichts wird allein aufgrund eines Dateinamens oder eines Formularfelds angewendet. Die Software liest den Upload und versucht, die Steuergerätefamilie aus dem Inhalt der Datei zu erkennen, zusammen mit Hardware- und Softwarekennungen, sofern die Datei sie enthält. Auslesungen, die nicht als Basis dienen können, werden in diesem Schritt ebenfalls erkannt: eine fast leere Teilauslesung, ein EEPROM-Dump oder ein Vollbackup, das mehr als den Flash enthält. In diesen Fällen erfahren Sie, welche Datei benötigt wird, statt Operationen angeboten zu bekommen. Die Auslesearten sind in unserem Ratgeber dazu, welche ECU-Datei Sie hochladen sollten, beschrieben.

Die Erkennung setzt auch eine harte Grenze für alles, was danach kommt. Lässt sich das Steuergerät nicht erkennen, wird kein Prüffeld auf Verdacht in die Datei geschrieben.

Schritt 2: Donor-Abgleich

Jede Lösung in der Bibliothek wurde aus einem realen Dateipaar gelernt: einer Original-Auslesung und der daraus erstellten modifizierten Datei. Die Originalhälfte dieses Paars nennen wir Donor. Wenn Sie eine Datei hochladen, sucht die Software nach Donoren derselben Steuergerätefamilie und vergleicht Ihre Datei Bereich für Bereich mit dem Donor-Original.

Drei Ergebnisse sind möglich.

Ihre Datei stimmt exakt mit einem Donor-Original überein. Die gelernte Änderung kann dann Byte für Byte übertragen werden.

Ihre Datei ist eine Variante: dieselbe Familie, aber ein anderer Softwarestand, sodass Kennfelder an anderen Positionen liegen oder andere Serienwerte enthalten. Die Software kann eine gelernte Änderung verschieben, wenn die umgebenden Daten die Position bestätigen. Weichen die Serienwerte in Ihrer Datei von denen des Donors ab, wird die Änderung nicht geschrieben. Das ist eine bekannte Grenze der aktuellen Engine und kein seltener Sonderfall: Eine Datei mit einem Softwarestand, den wir nicht gelernt haben, kann mit einer abgelehnten Operation zurückkommen.

Kein Donor passt. Die Operation wird dann für Ihre Datei nicht als Karte angeboten. Eine fehlende Karte ist hier die ehrliche Antwort; eine Karte, die verfügbar aussieht und später scheitert, ist das, was wir abschaffen wollen.

Derselbe Vergleich erkennt Arbeit, die bereits in der Datei steckt. Wurde eine Operation auf die hochgeladene Auslesung bereits angewendet, sagt die Karte das, und sie kann kein zweites Mal bestellt werden.

Schritt 3: Segmentprüfung

Eine gelernte Lösung wird als Liste von Segmenten gespeichert. Jedes Segment enthält eine Adresse, die Originalbytes, die modifizierten Bytes und ein kurzes Stück Kontext davor und danach. Das macht eine Prüfung zum Zeitpunkt des Schreibens möglich.

Bevor ein Segment geschrieben wird, wird der Zielbereich in Ihrer Datei mit den Originalbytes des Donors verglichen. Das Segment wird nur dort geschrieben, wo beide übereinstimmen. Ein Bereich, der ähnlich aussieht, aber nicht dasselbe Kennfeld ist, wird übersprungen statt überschrieben. Nach dem Schreiben wird das Ergebnis erneut gemessen: wie viele Segmente jeder gewählten Operation tatsächlich in der Datei angekommen sind.

Diese Regel kostet Abdeckung. Sie ist der Grund für die oben genannte Variantengrenze. Wir behalten sie bei, weil die Alternative wäre, Tuning-Werte über Daten zu schreiben, die die Software nicht versteht.

Schritt 4: die Lieferschranke

Das Ergebnis der Segmentprüfung speist eine Schranke vor dem Download. Konnte eine der von Ihnen gewählten Operationen nicht angewendet werden oder passte sie nicht vollständig auf die Datei, wird der Auftrag ohne Lieferung geschlossen. Die Meldung nennt die Operation, zum Beispiel: „Die gewählte Operation passte nicht vollständig auf diese Datei ... Damit Sie keine halb bearbeitete Datei erhalten, wurde das Ergebnis nicht geliefert.“ Das für diesen Auftrag abgebuchte Guthaben wird Ihrem Konto wieder gutgeschrieben.

Diese Schranke wird genutzt, und wir zeigen die Zahl lieber, als sie zu verbergen. In den 30 Tagen bis zum 9. Oktober 2026 wurden 12,6 % der Bearbeitungsaufträge auf der Plattform, unsere eigenen Büroaufträge eingeschlossen, an dieser Schranke geschlossen statt geliefert. Die Hälfte davon waren Operationen, die nicht vollständig passten, die andere Hälfte Operationen, die gar nicht angewendet werden konnten. Jede davon ist eine Datei, die ein Kunde nicht erhalten hat, und zugleich eine Datei, die nicht halb bearbeitet in ein Fahrzeug gelangt ist.

Was eine gelieferte Datei Ihnen nicht sagt

Ein Download ist keine Aussage, dass alles an der Datei nachgewiesen wurde. Vier Grenzen stehen in der Software selbst.

Checksum ist nicht Teil der Lieferung. Die gelieferte Datei enthält nur die Lösungsbytes, und der Bildschirm sagt, dass die Checksum nicht korrigiert wurde. Die Korrektur ist ein eigener Schritt in einem eigenen Reiter, und Steuergeräte mit moderner signierter Verifikation brauchen ein externes Werkzeug. Die Einzelheiten stehen im Beitrag So läuft der Checksum-Ablauf.

Manche Ergebnisse sind als vorläufige Ausgabe gekennzeichnet. Wurde ein Ergebnis aus einem gelernten Muster statt aus einem exakten Donor gebildet, enthält es möglicherweise nur einen Teil der Segmente des Donors. Die Schranke entscheidet, ob die Operation in Ihrer Datei angekommen ist, nicht ob jedes Donor-Segment übertragen wurde. Eine solche Datei wird mit dem Hinweis „Vorläufige Ausgabe — technische Prüfung vor dem Flashen“ geliefert, und dieser Hinweis meint, was er sagt.

DTC-Ergebnisse tragen eine eigene Warnung. Wurden Fehlercodes nur in der Codetabelle gelöscht, ist das Ergebnis mit „Wirksamkeit nicht geprüft“ markiert: Die Fehlerüberwachung des Steuergeräts wurde nicht geändert, und die Warnleuchte kann weiterhin aufleuchten.

Keine Dateiprüfung ersetzt eine Prüfung in der Werkstatt. Bewahren Sie die Original-Auslesung auf, bewahren Sie ein mit Ihrem Gerät erstelltes Vollbackup auf, und testen Sie auf dem Prüftisch oder im Fahrzeug. Die Software vergleicht Bytes; sie fährt das Auto nicht.

Wie wir die Prüfungen prüfen

Schranken können unbemerkt kaputtgehen, deshalb werden sie an realer Arbeit gemessen.

Jede Nacht werden frühere Lieferungen mit dem aktuellen Code erneut erzeugt und Byte für Byte mit der damals gelieferten Datei verglichen. Im Lauf vom 9. Oktober 2026 wurden fünf frühere Aufträge neu erzeugt: vier waren identisch, einer wich ab, und dieser wurde als verbessert eingestuft, weil mehr von der gewählten Operation angewendet wurde als bei der ursprünglichen Lieferung. Keiner war schlechter.

Nach dem Release vom 9. Oktober 2026 haben wir außerdem die angebotenen Karten gegen 40 reale Dateien laufen lassen. Von 157 Operationskarten, die die Software anbot, ergaben 155 eine gelieferte Datei. Die übrigen zwei wurden an der Lieferschranke von einer unabhängigen Prüfung gestoppt. Diese zwei Karten hätten gar nicht erst angeboten werden dürfen, und diese Lücke zu schließen ist offene Arbeit auf unserer Seite.

Die zweite Zahl veröffentlichen wir aus demselben Grund, aus dem es die Schranke gibt: Eine Karte, die nach dem Klick scheitert, ist ein Fehler, und die Messung ist der Weg, ihn zu finden.

Wie es weitergeht

Wie die Software vom Upload bis zum Download aufgebaut ist, beschreibt die Seite zur Chiptuning-Software. Um zu sehen, was sie in Ihrer eigenen Auslesung erkennt, erstellen Sie ein kostenloses Konto und laden Sie eine Originaldatei aus Ihrem Gerät hoch.