Pipeline-Automatisierung ist erst der Anfang

Automotive-Softwaresysteme zählen zu den komplexesten Softwaresystemen der Industrie. Ein heutiges Premiumfahrzeug läuft mit Hunderten Millionen Zeilen Code, während Softwarefehler zur schnellst wachsenden Rückrufursache geworden sind. ADAS, OTA-Updates, Zonen- und Zentralrechner-basierte E/E-Architekturen sowie autonomes Fahren verschärfen diese Komplexität. Die Herausforderung ist sicherheitskritische Software in der vom Markt geforderten Geschwindigkeit zu entwickeln, validieren und freizugeben.

CI/CD war vor Jahren ein Buzzword, heute ist es operative Notwendigkeit. Wer auf manuelle Integrationszyklen setzt, ist im SDV-Zeitalter nicht mehr wettbewerbsfähig. CI/CD ist die tragende Säule des aktuellen Software-Auslieferungsprozesses im Automotive-Sektor.

CI/CD in der Automotive-Softwareentwicklung

Führende OEMs haben den Übergang von Pilotprojekten zu industriellen CI/CD-Prozessen vollzogen. Bekanntes Beispiel: die AWS-basierte „Software Factory“ von BMW, die laut AWS-Fallstudie (2024) über 12.000 Entwickler unterstützt, täglich bis zu 140.000 CI-Jobs ausführt und 50 wiederverwendbare Pipeline-Bausteine bereitstellt.

Standard ist heute automatisiertes Build-Triggering bei jedem Commit, statische Code-Analyse nach MISRA/AUTOSAR, automatisierte Tests, Compliance-Prüfungen nach ISO 26262/ASPICE sowie qualitätsgesicherte Freigabestufen. Der Markt für Automotive-DevOps/CI/CD wächst mit einer CAGR von 24 Prozent bis 2034.

CI/CD-Grundlagen und „Everything-as-Code“-Erweiterungen

Reine CI/CD-Pipelines reichen für die Softwarekomplexität nicht mehr aus. Die nächste Reifestufe ist die Software Factory: eine industrialisierte DevOps-Umgebung, die Entwicklung, Integration, Test und Deployment vereint. Mit ihr hat sich „Everything-as-Code“ (XaC) als äußerst wirkungsvolle Erweiterung etabliert: Infrastruktur, Pipeline-Definitionen, Entwicklungs-/Testumgebungen und Konfigurationen werden als versionierte, maschinenlesbare Artefakte abgebildet; das verbessert Reproduzierbarkeit, Traceability und Skalierbarkeit.

Praktisch kombiniert eine Software Factory die CI/CD-Orchestrierung mit Automatisierungsansätzen, die auf das ASPICE V-Modell ausgerichtet sind, unabhängig von Architektur oder Middleware-Stack. Die einmalige Setup-Phase erstellt Projekt-, Tool- und Pipeline-Konfigurationen sowie standardisierte Entwicklungs-/Testumgebungen, innerhalb derer alle nachgelagerten Aktivitäten orchestriert werden. 

Everything as Code für Entwicklung, Test und Validierung

Ausgerichtet auf ASPICE SYS.3 erfolgt der Entwurf der Systemarchitektur meilensteingesteuert und wird vollständig als Code erfasst, sodass das Architekturmodell versioniert, maschinenlesbar und durchgängig rückverfolgbar bleibt. Eine sprintbasierte Mikro-V-Schleife bildet das Herzstück des iterativen Prozesses und vereint die ASPICE-Schritte (SWE.1–SWE.6) „als Code“: Anforderungen, Architektur, Unit-Design und Testspezifikationen. Dokumentationen werden über Docs-as-Code gepflegt, was Pull-Request-Workflows und automatisierte Konsistenzprüfungen ermöglicht.

Eine Schlüsselrolle spielt „Shift-Left“: Da Tests größtenteils virtuell (vECU/SiL) laufen, sinkt der Bedarf an teuren HiL-Prüfständen drastisch; physische Hardware ist im Wesentlichen nur noch für die finale Fahrzeug-Validierung nötig, auch diese wird über Infrastructure-as-Code reproduzierbar verwaltet.

In nachgelagerten Phasen wendet die Software Factory XaC auch auf Traceability Enforcement, OTA-Deployment und Monitoring an. Traceability-Regeln verknüpfen jede Anforderung mit Code und Tests; CI-Builds schlagen bei Lücken automatisch fehl. Monitoring- und KPIs-as-Code versionieren Dashboards und Alarmierungsregeln, somit schließt sich der Kreis von Felddaten zurück zu Anforderungen und Architektur.

Performance als Schwachstelle in der CI/CD-Pipeline

CI/CD ist im Automotive-Bereich mit Herausforderungen verbunden: Dependency-Management über komplexe Lieferketten, Validierung von KI-generiertem Code und heterogene Tool-Landschaften – reale Probleme, die hier aber nicht vertieft werden, da sie Gegenstand aktiver Tool-Entwicklungen sind.

Am wenigsten beachtet, aber rasant an Brisanz gewinnend, ist die Software-Performance in der Continuous Integration: die Integration nicht-funktionaler Performance-Validierung als vollwertiges CI-Gate. Klassische Pipelines fragen fast nur: Ist der Build fehlerfrei, bestehen die Tests, sind funktionale Anforderungen erfüllt? Das war vertretbar, solange Hardware-Engpässe durch schnellere Prozessoren kompensiert wurden. Mit dem Ende von Moore’s Law existiert dieses Sicherheitsnetz nicht mehr: Heterogene Automotive-SoCs liefern nur dann enorme Leistung, wenn die Architektur sie effizient nutzt.

Infolgedessen treten architektonische Sackgassen auf – Softwarestrukturen, die Hardware-Parallelität nicht effizient nutzen. Solche Probleme sind im Nachgang extrem teuer zu korrigieren, wenn sie erst spät im V-Modell entdeckt werden. Die Ursache ist fast immer architektonischer Art: eine früh getroffene Design-Entscheidung wurde nie gegen reale Performance-Vorgaben validiert, weil die Pipeline kein Performance-Feedback lieferte.

Mehr Rechenleistung für die Ära softwaredefinierter Fahrzeuge

Softwaredefinierte Fahrzeuge erhöhen den Bedarf an zentraler Rechenleistung erheblich. Skalierbare Plattformen mit Chiplet-Erweiterung und offenen Toolchains schaffen die Grundlage, um Leistung, Softwarekontinuität und lange Automotive-Lebenszyklen zusammenzuführen.

Peter Bechberger

Architektur und Performance kontinuierlich validieren

Der RT-RK-Ansatz stützt sich auf drei Prinzipien: frühzeitige Definition messbarer Performance-Metriken, auch bei nur teilweise verfügbarer, emulierter Zielhardware; kontinuierliches Performance-Feedback bei jeder signifikanten Änderung, analog zum funktionalen Testen; und Architektur als Artefakt erster Klasse, das denselben Governance-Schleifen unterliegt wie der Code.

Dieses dritte Prinzip untermauert das Data Quintet: Anforderungen, Architektur, Tests, Code und Build-Spezifikation definieren Software gemeinsam eindeutig. Eine ausgereifte Pipeline muss Konsistenz über alle fünf Bereiche sicherstellen. Der RT-RK Alteration Layer legt eine Konsistenz-Governance über die Standard-Toolchain: Eine Änderung an einem Quintett-Element stößt automatisch Updates für die anderen an. Da KI-generierter Code Volumen und Unvorhersehbarkeit erhöht, wird die Sicherstellung dieser Konsistenz zur kritischsten Disziplin der Automotive-Softwareentwicklung.

Performance-Tests als CI-Gate für Automotive-Software

Performance-Benchmarking als CI-Gate ist die unmittelbarste Maßnahme: Repräsentative Workloads werden automatisch in der Pipeline ausgeführt und gegen Pass/Fail-Schwellenwerte geprüft. Für rechenintensive Funktionen ist dies etabliert, für Steuerungs-/Kommunikationssoftware jedoch noch selten systematisch im Einsatz.

Architektonische Fitness-Funktionen – automatisierte Prüfungen architektonischer und Performance-Vorgaben – stellen die nächste Reifestufe dar. Der RT-RK Alteration Layer generalisiert diese Governance und erzwingt jede codierte Architekturvorgabe automatisch im CI-Build.

Der Aufstieg von KI-generiertem Code verstärkt Chancen und Risiken: KI-Codegeneratoren beschleunigen die Implementierung, sind aber gegenüber Performance-Architektur weitgehend agnostisch – sie optimieren auf Korrektheit, nicht auf Systemeffizienz. CI/CD-Pipelines mit Performance-Gates werden damit zum unverzichtbaren Qualitätsfilter für KI-unterstützte Entwicklung.

Digitale Zwillinge in der Fahrzeugentwicklung

Digitale Zwillinge tragen dazu bei, die Designmethodik von Halbleitern und Systemen in der Automobilindustrie neu zu gestalten. Sie ermöglichen die Entwicklung von wirklich softwaredefinierten Fahrzeuge.

Conhas Thakkar

CI/CD für die Praxis entwickeln

Die Implementierung einer CI/CD-Umgebung auf Automotive-Niveau ist kein Produkt von der Stange. Jedes OEM- und Tier-1-Programm hat eine einzigartige Kombination aus Toolchains, Lieferantenschnittstellen, Codebeständen und Sicherheitsstandards – gefragt sind CI/CD-Expertise, Automotive-Domänenwissen und Entwicklungskapazität.

Automobilhersteller und Zulieferer benötigen drei Dienstleistungskompetenzen: CI/CD-Consulting mit Ist-Analyse, Ziel-Architektur und Implementierungs-Fahrplan; maßgeschneiderte Pipeline-Entwicklung auf Basis etablierter Tools wie Jenkins, GitLab, Docker, Ansible und SiL/HiL-Orchestrierung; sowie Skalierung des DevOps-Teams durch Integration spezialisierter externer Ingenieure in die Kundenorganisation.

Effektives CI/CD im Automotive-Sektor erfordert Know-how an der Schnittstelle von Softwarearchitektur, Automotive-Standards und praktischer DevOps-Implementierung. RT-RK bietet genau diese Kombination – ergänzt durch den RT-RK Alteration Layer, der die automatisierte Durchsetzung von Architekturvorgaben direkt in die CI-Pipelines bringt. (na)