ECU Studio AI 1.18.0

Hinweis (04.11.2026): Diese Version enthält gelernte Daten (candidate_model.json,
ms43_430069_structure_model.json, confidence_calibration.json), deren Trainings- bzw. Messdaten teilweise
keine dokumentierte Herkunft oder Freigabe haben. Ab 1.19.0
sind diese Dateien entfernt, und die App zeigt statt gemessener Prozentwerte die Art des Belegs. Wir empfehlen,
auf die aktuelle Version zu aktualisieren. Details:
Modellkarte, Abschnitt 2e.

Notice (4 Nov 2026): This version contains learned data (candidate_model.json,
ms43_430069_structure_model.json, confidence_calibration.json) whose training or measurement data partly has
no documented provenance or clearance. From 1.19.0
on, these files are removed, and the app shows the kind of evidence instead of measured percentages. We recommend
updating to the current version. Details:
model card, section 2e
(German).

• Offline zuerst: automatische Update-Prüfung ab Werk aus. Ohne eigene Einstellung baut ECU Studio AI keine
  Netzwerkverbindung mehr von selbst auf. „Einstellungen → Automatisch nach Updates suchen“ schaltet sie ein; eine
  bereits gespeicherte Wahl (ein oder aus) bleibt erhalten. „Jetzt nach Updates suchen“ funktioniert unverändert.
  Die Prüfung fragt nur die GitHub-Releases-API ab und sendet keine Dateien.

• Lokale Referenzsuche beim Öffnen einer BIN: Projekte und Kennfeldpakete werden jetzt auch über gleiche
  Hardware- und Softwarenummern gefunden (eigene indizierte Tabelle; ältere Einträge werden beim Öffnen aus den
  gespeicherten Metadaten ergänzt, ohne eine BIN zu lesen). Jeder Vorschlag zeigt Stufe und Grund: „nachgewiesen“
  nur bei identischer Datei (SHA-256), „wahrscheinlich“ bei gleicher Softwarenummer (mit oder ohne Hardware),
  „mehrdeutig“ bei nur gleicher Hardwarenummer oder Familie. Bisher zählten nur gleicher Hash und gleiche Familie,
  auf 50 Einträge begrenzt, sodass ein Projekt mit gleicher Softwarenummer fehlen konnte. „Bestehende Projekte
  indexieren …“ schreibt in wenigen Transaktionen statt einer je Projekt, zeigt Fortschritt, lässt sich abbrechen
  und meldet Fehler gesammelt. Synthetischer Benchmark mit 20 000 Projekten und 2 000 Paketen
  (python -m ecu_studio.tools.library_benchmark): Datenbankanteil je indiziertem Projekt 17,4 → 0,27 ms,
  Vorschläge beim Öffnen 25,5 → 28,2 ms, einmalige Ergänzung beim ersten Öffnen 0,3 s.

• Definition bearbeiten und XDF-Export, Fehlerbehebungen: Eine strukturelle Änderung (Adresse, Größe,
  Datentyp, Byte-Reihenfolge, Faktor/Offset, Achsenadresse oder -werte) setzt den Prüfstatus einer geprüften
  Definition jetzt zurück; nur ein ausdrücklicher Klick auf „Fachlich geprüft“ bestätigt ihn erneut. Vorher blieb
  er mit einer Warnung bestehen. Eine gespeicherte Achsenadresse lässt sich im Dialog durch Leeren des Feldes
  entfernen (vorher blieb sie erhalten). Der XDF-Export schreibt in eine temporäre Datei, prüft sie per Rückimport
  und ersetzt das Ziel erst danach in einem Schritt; bei Abweichung oder Schreibfehler bleibt eine vorhandene Datei
  unverändert. Die Rückimport-Prüfung verglich bisher falsche Paare, sobald eine ungültige Definition im Katalog
  stand, und meldete dann fälschlich „Datei nicht verwenden“. Der Bericht sagt jetzt ausdrücklich, dass der
  Rückimport mit dem eigenen Import erfolgt und kein Test in TunerPro ist.

• Firmware-Schutz für das Repository: Pre-Commit- und Pre-Push-Hooks (.githooks/, aktivieren mit
  python src\ecu_studio\tools\firmware_guard.py install) blockieren Firmware-, Dump-, Definitions-, Archiv- und
  Datenbankdateien, umbenannte Binärdateien, eingebettete Hex-/Base64-/Intel-HEX-Daten, Dateien über 1 MiB, private
  Datenordner und den konfigurierten lokalen Datenordner. Geprüft wird der Index (auch bei selektivem Staging) bzw.
  jeder ausgehende Commit samt Commit-Nachricht und dem ganzen gepushten Baum. Öffentliche Ausnahmen (synthetische
  Beispiele, mitgelieferte GPL-XDFs) gelten nur für Pfad + SHA-256. CI prüft den Baum erneut. Die bisherige Historie
  wurde vollständig geprüft: keine Firmware (Beschreibung und Restrisiken).

• Dokumentation und App-Daten aktualisiert: „Hilfe → Unterstützte Steuergeräte“ führt MSD80 jetzt als TriCore
  (vorher PowerPC), MSD85 als ungeprüft und Delco Multec S als nicht validiert; Messwerte unverändert. PROGRESS.md mit
  den TriCore-Stufen, Roadmap-Grafik auf 1.17.0, Modellkarte mit den heutigen Trefferquoten je Beweisart und dem
  Lernmodell, Beweisart-Tabelle der README an die Kalibrierdaten angeglichen. Herkunftsangaben zu nicht
  mitgelieferten Referenz- und Trainingsdateien entfernt, ebenso firmware_holdout sources samt Quellenliste.

• TriCore-Zelltyp aus dem Programmcode (MSD80): Breite und Vorzeichen einer Tabelle folgen aus den
  Ladebefehlen ihrer Interpolationsroutine, deren Basis vom Tabellenzeiger a4 abgeleitet ist; nur bei
  übereinstimmenden Zugriffen, sonst bleibt der Typ als ungeprüft markiert. Diese Breite hat Vorrang vor einer
  zufällig exakt gefüllten Lücke (22 von 832 Fällen: zwei gleich große Bytetabellen hintereinander). Alle per
  a4 an bekannte Kennfeldroutinen übergebenen Adressen begrenzen jetzt die Lücke. Eine Kennfeldroutine nach
  Achsensuche muss Tabellenzellen lesen. MSD80 I8A0S (Entwicklungsdaten): exakt 71 → 73 von 99, Typ richtig
  53 → 62, Konflikte unverändert; MS42/MS43, Negativkontrollen und EDC17C69 unverändert
  (Bericht, Abschnitt 11).

• Delco D98 / Multec S: Recherche dokumentiert; kein rechtmäßig nutzbares Abbild gefunden, daher keine
  Erkennungsmetrik (Recherche, Benchmark).

• TriCore-Aufrufe, zweite Stufe (MSD80): Achszeiger, die eine Funktion früh auf dem Stack ablegt und erst
  vor dem Aufruf wieder lädt, werden über die nächste vorangehende Belegung des Slots aufgelöst (nur bei
  einmaliger sp-Änderung und ohne herausgegebene Slotadressen). Getrennte Interpolation (Achsensuche je Achse,
  danach Kennfeldaufruf nur mit Daten) wird pfadgebunden erkannt; Routinenrollen folgen aus dem Aufrufverhalten,
  die Zellbreite nur aus exakter Lückenfüllung. Eigene, nicht kalibrierte Evidenzklasse code:call-pre.
  MSD80 I8A0S (Entwicklungsdaten): exakte 2D-Kennfelder 61 → 71 von 99, Konflikte mit der XDF 13 → 11,
  Gruppenpaare 17 → 33. MS42/MS43, alle Negativkontrollen und EDC17C69 unverändert. Behoben: 16-Bit-ld.a a15,[sp]
  verwarf den alten a15-Wert nicht (Bericht, Abschnitt 10).

• Kennfelder aus TriCore-Interpolationsaufrufen (Siemens MSD80 und andere Vollflash-Images mit derselben
  Aufrufkonvention): Der Code übergibt Tabellendaten in a4 und die Köpfe von X-/Y-Achse in a5/a6. Der neue
  Decoder core/tricore_refs.py liest daraus Start, Größe und Achsen; die Zellbreite folgt ohne Referenz aus dem
  nächsten benannten Objekt. Gemessen an einem MSD80-Vollflash (I8A0S, Community-XDF, Entwicklungsdaten): exakte
  2D-Kennfelder 39 → 61 von 99, Kennlinien 115 → 160 von 262, gemeinsame Achsen 17/17. Keine neue Kollision mit
  der Referenz; MS42/MS43 und alle Negativkontrollen unverändert; EDC17C69 bleibt ohne Treffer. Eigene,
  nicht kalibrierte Evidenzklasse code:call. Reine Kalibrierbereiche (S19) enthalten keinen Code und bleiben
  unverändert. MSD80 ist nachweislich TriCore, nicht PowerPC
  (Bericht).

• Kennfelddefinition bearbeiten / prüfen … (Strg+E, Werkzeuge und Kontextmenü der Kennfeldliste): Name,
  Beschreibung, Adresse, Größe, Datentyp, Byte-Reihenfolge, Faktor/Offset, Einheiten, X-/Y-Achsenadresse mit eigenem
  Datentyp und Faktor, Prüfstatus. „Prüfen“ zeigt Änderungen, Warnungen und eine Vorschau der Werte aus den
  aktuellen Dateibytes; „Übernehmen“ erst danach und nur nach Bestätigung, als rückgängig machbare
  Definitionsänderung. Die BIN wird nie verändert; „geprüft“ setzt nur der Nutzer. Achsen werden nur neu gelesen,
  wenn der Nutzer ihre Leseart ändert (sonst blieben importierte Achsen mit unbekannter Skalierung nicht erhalten).

• Kennfelder als TunerPro-XDF exportieren … (Datei-Menü): XML-XDF 1.70 für Tabellen, Kennlinien und Konstanten
  mit 8/16/32 Bit, Vorzeichen, Byte-Reihenfolge, Speicherordnung, Strides, Formel, Einheiten und Ordner. Achsen als
  feste Stützstellen (folgen keiner späteren Achsenänderung). 32-Bit-Gleitkomma und ungültige Definitionen werden
  mit Grund ausgelassen. Jeder Export wird sofort mit dem eigenen XDF-Importer zurückgelesen und Feld für Feld
  verglichen; nur dann meldet die App „Rückimport geprüft“. In TunerPro selbst ist der Export nicht getestet.

• Konfidenzfilter „Noch nicht manuell geprüft“: alle Kennfelder, die der Nutzer noch nicht bestätigt hat.

• Open-Source-Detektoren am fixierten Quellstand verglichen; zwei eigenständig implementierte Strukturversuche
  bleiben außerhalb des produktiven Scanners. Neuer tools.detector_benchmark nutzt die bestehenden
  hashgebundenen Messungen für Baseline, Einzelversuch und konservative Kombination.

• Negative Achszeiger werden vor dem Bytezugriff abgewiesen; keine Dateiumwicklung durch Python-Indizierung.

• Wiederholte Record-Oberflächenprüfungen werden pro Scan begrenzt wiederverwendet. Auf der synthetischen
  64-KiB-Rampenkontrolle sinkt der Median von 35,965 auf 8,750 s bei identischen Resultaten; kein allgemeiner
  ECU-Geschwindigkeitsfaktor. Neue reale Kennfeldtreffer sind nicht nachgewiesen.

• Quellcodevergleich, Herkunft, Messungen und Grenzen.

---

Installation: ECU-Studio-AI-<version>-windows-x64.zip entpacken und ECU-Studio-AI.exe starten, oder den
Installer ECU-Studio-AI-<version>-setup.exe ausführen. Bestehende Installationen bieten das Update automatisch an.

Windows-Warnung beim ersten Start: Die EXE ist noch nicht code-signiert. Bei „Der Computer wurde durch Windows
geschützt“ auf „Weitere Informationen“ → „Trotzdem ausführen“ klicken. Echtheit prüfen: SHA-256 gegen die
.sha256-Datei, Build-Herkunft mit gh attestation verify <datei> --repo PCTestAdmin/ECU-Studio-AI.