Tooling: die Engineering-Domäne auf beiden Seiten des V-Modells und warum KI sie nicht ersetzt
Was Engineering-Tooling ist, wo es im V-Modell und im Softwarelebenszyklus steht, warum KI es nicht ersetzen kann und wie KI es stärker macht. Mit Beispielen aus 14 Jahren Werkzeugentwicklung für Entwicklung, Test, Produktion und Service in der Automobilindustrie.
Bei Automobilsoftware denken die meisten an den Code im Fahrzeug. Hinter jedem Steuergerät steht jedoch eine zweite Welt aus Software: die Werkzeuge, mit denen Ingenieure es spezifizieren, bauen, kalibrieren, testen, freigeben, produzieren und warten. Seit mehr als 14 Jahren baue ich an dieser zweiten Welt, und ich bin überzeugt, dass sie wichtiger ist denn je, gerade jetzt, wo KI verändert, wie Software geschrieben wird.
Was „Tooling“ bedeutet
Engineering-Tooling ist die Software, mit der Engineering-Teams ein Produkt erstellen und prüfen, nicht das Produkt selbst. In der Automobilentwicklung gehören dazu:
- Entwicklungswerkzeuge: IDEs, Compiler, Codegeneratoren und Kommunikationsstacks.
- Daten- und Kalibrierwerkzeuge: Verwaltung, Validierung und Auslieferung von Kalibrierparametern und Messdaten.
- Testwerkzeuge: Testautomatisierung, Prüfstandssteuerung, Busanalyse und Auswertung von Ergebnissen.
- Produktions- und Servicewerkzeuge: End-of-Line-Kalibrierung, ECU-Flashing und Werkstattdiagnose.
Gemeinsam ist diesen Werkzeugen: In ihnen werden Engineering-Methoden wiederholbar. Ein gutes Tool macht aus dem manuellen Ablauf eines Experten etwas, das ein ganzes Team jedes Mal auf dieselbe Weise ausführen kann.
Tooling auf beiden Seiten des V
Das V-Modell beschreibt die Entwicklung als Weg die linke Seite hinab (von den Anforderungen bis zur Implementierung) und die rechte Seite hinauf (vom Unit-Test bis zur Abnahme). Tooling wird bei jedem Schritt auf beiden Seiten gebraucht und auch jenseits des V, in Produktion und Service:
| Phase | Was Tools dort leisten | Beispiele aus meiner Arbeit |
|---|---|---|
| Anforderungen und Systemarchitektur | Konsistenz prüfen, Nachverfolgbarkeit sichern, Testfälle ableiten | Vergleichstool für Systemarchitekturen: markiert Inkonsistenzen zwischen Architekturelementen in Polarion und erzeugt Testfälle mit generativer KI |
| Softwareentwurf und Implementierung | Kompilieren, Code generieren, mit Steuergeräten kommunizieren | Cross-Compiler-IDE für AVR- und ARM-Controller; geschichteter CAN/UDS-Kommunikationsstack; aus OpenAPI generierter C#-API-Client |
| Kalibrierung und Integration | Kalibrierdaten und Software-Builds verwalten, validieren und ausliefern | Modernisierung der CRETA Export Engine; Pipeline zur Auslieferung von Kalibrierdaten; regelbasierte Validierung von Kalibrierlabels mit CaRuMa |
| Unit- und Integrationstest | Tests automatisieren, Prüfstände steuern, Busverkehr analysieren | CAN-Bus-Analysator; CArray Creator für Prüfstandssequenzen; Release-Pipeline für Prüfstandssoftware |
| Systemtest und Validierung | Große Messdatensätze verarbeiten und auswerten | Measurement Class Library; xD_MapCreator für mehrdimensionale Kennfelder; HPC-Verarbeitung, die die Auswertung von Stunden auf Minuten verkürzt hat |
| Jenseits des V: Produktion und Service | Am Bandende kalibrieren und flashen, in der Werkstatt diagnostizieren | End-of-Line-Kalibriertool für Inverter mit CRC-Patching; Bootloader- und Flash-Tool; Werkstatttester VDO Autodiagnos Check |
Tooling unterstützt auch den Lebenszyklus als Ganzes: Reifegrad-Dashboards, Prognosen des Restaufwands und automatisierte Berichte geben Projektleitungen einen Überblick, den kein einzelner Ingenieur von Hand zusammenstellen könnte.
Genau das macht Tooling zu einer eigenen Domäne. Es braucht Entwicklungswissen (wie Software gebaut wird), Testwissen (wie sie geprüft wird) und Domänenwissen (Kalibrierung, Diagnose, Messtechnik), oft im selben Werkzeug.
Warum KI Tooling nicht ersetzen kann
KI verändert, wie Werkzeuge gebaut und genutzt werden. Überflüssig macht sie sie nicht, aus sechs Gründen:
- KI handelt über Werkzeuge. Ein KI-Agent, der „die Tests ausführt“ oder „das Steuergerät flasht“, ruft dafür ein Werkzeug auf. Ohne verlässliche Schnittstellen zu Compilern, Prüfständen und Messsystemen hat KI nichts, worauf sie wirken kann. Bessere KI erhöht den Bedarf an guten Werkzeugen, nicht umgekehrt.
- Freigaben brauchen Reproduzierbarkeit. Eine Freigabe, ein Regressionstest oder eine Kalibrierlieferung muss bei gleicher Eingabe dasselbe Ergebnis liefern. Deterministische Werkzeuge leisten das; die Antwort eines Sprachmodells kann sich von Lauf zu Lauf unterscheiden.
- Sicherheitsnormen verlangen Vertrauen in Werkzeuge. Die ISO 26262, die Norm für funktionale Sicherheit von Straßenfahrzeugen, fordert für Softwarewerkzeuge ein Tool Confidence Level, abhängig davon, wie sich ein Werkzeugfehler auf die Sicherheit auswirken kann und wie wahrscheinlich er erkannt wird. Werkzeuge in den höheren Stufen müssen qualifiziert werden. Für KI/ML-basierte Werkzeuge weist Renesas darauf hin, dass ihre Ergebnisse schwer zu prüfen sind; meist muss daher eine niedrige Fehlererkennung angenommen werden, was die Qualifizierung erschwert.
- Die physische Welt hat Protokolle und Timing. Steuergeräte, CAN- und UDS-Kommunikation, Leistungsanalysatoren und Prüfstände brauchen Treiber, exakte Protokolle und Echtzeitverhalten. Das ist Ingenieursarbeit, keine Textgenerierung.
- Audits brauchen Nachweise. Anforderungen, Tests und Ergebnisse müssen nachverfolgbar und dokumentiert sein. Werkzeuge erzeugen und speichern diese Nachweise in einer Form, die in Reviews und Audits Bestand hat.
- Daten in großem Umfang brauchen Pipelines. Die Auswertung großer Messkampagnen ist eine Data-Engineering-Aufgabe: Formate, Speicher, Cluster-Jobs und Integritätsprüfungen. KI kann helfen, Ergebnisse zu interpretieren, aber die Arbeit macht die Pipeline.
Wo KI hineinpasst: in die Werkzeuge und in ihre Entwicklung
Die richtige Frage ist nicht „KI oder Werkzeuge?“, sondern „Wo macht KI Werkzeuge besser?“:
- KI in Werkzeugen: Mein Architektur-Vergleichstool nutzt generative KI, um Inkonsistenzen zu finden und Testfälle vorzuschlagen, und ein Machine-Learning-Modell prognostiziert den verbleibenden Engineering-Aufwand. In beiden Fällen übernimmt das Werkzeug um das Modell herum Daten, Validierung und Darstellung.
- KI für die Entwicklung von Werkzeugen: Ich nutze täglich Coding-Agenten wie Claude Code, GitHub Copilot und Gemini CLI für Grundgerüste, Tests und Dokumentation. Sie beschleunigen die Werkzeugentwicklung, und jede Änderung wird weiterhin geprüft und getestet.
Mein Grundsatz: KI schlägt vor, Werkzeuge prüfen. KI ist hervorragend im Vorschlagen; deterministische, getestete Werkzeuge entscheiden, was korrekt ist.
Was das für Tooling-Ingenieure bedeutet
Tooling ist eine der wenigen Rollen, die jede Phase des Lebenszyklus berührt, von der ersten Anforderung bis zur Werkstatt. Diese Breite ist ihre Stärke: Tooling-Ingenieure verstehen, wie ein Produkt gebaut, getestet, produziert und gewartet wird, und machen aus diesem Verständnis Software, auf die sich andere verlassen.
Wenn KI mehr Routine-Programmierung übernimmt, erwarte ich, dass der Wert dieser Kombination steigt: Ingenieure, die die Domäne kennen, verlässliche Werkzeuge entwerfen und KI nutzen, um sie schneller zu bauen.
Fazit
- Tooling steckt überall im V: in jeder Phase, auf beiden Seiten, dazu in Produktion und Service.
- KI braucht Werkzeuge, um zu handeln: Reproduzierbarkeit, Vertrauen in Werkzeuge, Hardwarezugriff und Audit-Nachweise kommen von Werkzeugen.
- KI macht Werkzeuge stärker: in Werkzeugen als Funktion und bei ihrer Entwicklung als Beschleuniger. KI schlägt vor, Werkzeuge prüfen.
Quellen
- ISO: ISO 26262-8:2018 Straßenfahrzeuge – Funktionale Sicherheit – Teil 8: Unterstützende Prozesse
- Renesas: Confidence in the use of software tools for AI/ML development (2022, Englisch)
- Synopsys: Automotive tool confidence for ISO 26262 (Whitepaper, PDF, Englisch)
Mehr zu den hier genannten Werkzeugen unter Projekte.