CI/CD für Automotive und sicherheitskritische Embedded-Software
Wir bauen Pipelines für Steuergeräte-Software, die vom Commit bis zum signierten OTA-Update durchlaufen und die Nachweise für ISO 26262, ASPICE und ISO 21434 gleich mit erzeugen. Für Tier-1-Zulieferer und OEMs im DACH-Raum.
SEIT 2006 · 47+ PROJEKTE · AUTOMOTIVE · EMBEDDED · ISO 26262 · ASPICE · ISO 21434
Was ist CI/CD
für Automotive?
Die Kurzfassung für Projektleitung und Safety-Management, bevor es um Build-Zeiten, Prüfstände und Nachweise geht.
CI/CD für Automotive automatisiert Build, Test und Deployment sicherheitskritischer Embedded-Software, vom Cross-Compile bis zum signierten OTA-Update. Eine CI/CD-Pipeline für Automotive verbindet Yocto- oder Buildroot-Builds mit Software-in-the-Loop-Tests auf virtuellen Steuergeräten (SIL) und Hardware-in-the-Loop-Tests am Prüfstand (HiL) und erzeugt die Nachweiskette nach ISO 26262, ASPICE und ISO 21434 automatisch mit, statt sie vor dem Assessment von Hand zu rekonstruieren. Comquent baut solche CI/CD-Pipelines für Automotive seit 2006, als Teil unseres Industrial-DevOps-Ansatzes. Die Cybersecurity-Stages nach ISO 21434 und UNECE R155/R156 stützen sich auf unsere DevSecOps- & Compliance-Praxis.
Was ändert das Software Defined Vehicle an der Pipeline?
Im Software Defined Vehicle (SDV) hängt die Funktion nicht mehr am einzelnen Steuergerät, sondern an Software auf wenigen Hochleistungsrechnern, die über die Laufzeit des Fahrzeugs nachgeliefert wird. Für die Pipeline verschiebt das den Schwerpunkt: Ein Release ist nicht mit dem Start der Serie fertig, sondern muss Jahre später noch baubar, testbar und signierbar sein. Das erzwingt reproduzierbare Builds, ein gepflegtes Software-Bill-of-Materials und eine Teststrecke, die auch für Varianten aus dem Feld noch funktioniert.
Wer unterstützt OEMs und Zulieferer bei DevOps im Embedded-Umfeld?
Comquent unterstützt seit 2006 OEMs und Tier-1-Zulieferer im DACH-Raum bei DevOps und CI/CD im Embedded-Umfeld, herstellerneutral und auf Basis der Toolchain, die bereits im Einsatz ist. Am Markt gibt es drei Typen von Anbietern: Engineering-Dienstleister, die Entwicklungskapazität stellen, Toolhersteller, die ihre eigene Kette mitbringen, und Beratungen wie Comquent, die die vorhandene Toolchain automatisieren. Der Grund für diesen Weg ist praktisch: Eine qualifizierte Toolchain wird in der Regel nicht ausgetauscht, sondern automatisiert. Wie das im Maschinenbau aussieht, zeigt der Anwendungsfall Maschinenbau und SPS.
AIWas bremst Embedded-Teams
im Automotive?
An diesen Stellen bleiben Projekte in dieser Branche am häufigsten hängen. Wie wir sie angehen, steht im nächsten Abschnitt.
- /01
Lange Build-Zeiten für Embedded-Systeme
Ein Yocto- oder Buildroot-Build von Grund auf dauert Stunden. Ohne geteilten sstate-Cache und verteilte Build-Knoten fängt jeder Build wieder bei null an, und die Rückmeldung zur eigenen Änderung kommt erst, wenn der Kopf längst beim nächsten Thema ist.
- /02
Nachweise nach ISO 26262, ASPICE und ISO 21434
Sicherheitskritische Software im Automotive-Bereich muss ISO 26262 (Funktionale Sicherheit), Automotive SPICE (Prozessreife) und ISO 21434 (Cybersecurity) erfüllen, dazu die Typgenehmigung nach UNECE R155/R156. Fehlt die durchgängige Traceability, entsteht die Nachweiskette am Ende von Hand: Wochen vor dem Assessment sitzt jemand da und rekonstruiert aus Tickets, Mails und Build-Logs, welche Anforderung von welchem Test abgedeckt ist.
- /03
OTA-Updates für eine gemischte Flotte
Ein OTA-Update muss auf jedem Steuergerät im Feld ankommen, auch auf der Hardware-Revision von vor vier Jahren. Dafür braucht es signierte Artefakte, A/B-Partitionierung und einen Rollback, der ohne Werkstattbesuch funktioniert.
- /04
Manuelle Hardware-in-the-Loop-Tests
Am Prüfstand stößt jemand die HiL-Tests von Hand an und wertet sie von Hand aus. Die Regression dauert Tage, die Abdeckung bleibt lückenhaft, und weil sich mehrere Teams einen Prüfstand teilen, wartet der Release auf einen freien Slot.
Wie kommt CI/CD auf das
Steuergerät?
CI/CD kommt in vier Schritten auf das Steuergerät: Build-Analyse, eine Yocto- oder Buildroot-Pipeline mit geteiltem sstate-Cache, SIL- und HiL-Tests als Pipeline-Stages und signierte OTA-Pakete samt Nachweisen. Die Build-Analyse misst, wo heute die Stunden zwischen Commit und getestetem Image verloren gehen, und dort setzt die Pipeline zuerst an.
Assessment und Build-Analyse
Wir messen, wo die Zeit zwischen Commit und getestetem Image heute bleibt: im Build, in der Warteschlange am Prüfstand, in der manuellen Freigabe. Ein Value-Stream-Mapping zeigt die größten Zeitfresser, und aus ihnen ergibt sich die Reihenfolge der nächsten Schritte.
Yocto- und Buildroot-Pipeline
Wir bauen die CI-Pipeline mit geteiltem sstate-Cache, verteilten Build-Knoten und inkrementellen Builds, sodass eine Änderung nur neu baut, was sie betrifft. Jenkins oder GitLab CI steuern den Weg vom Commit bis zum fertigen Image, je nachdem, was bei Ihnen schon läuft.
SIL- und HiL-Tests in der Pipeline
Die Hardware-in-the-Loop-Prüfstände werden zur buchbaren Ressource der Pipeline, mit automatischer Testausführung, Reporting und Quality Gates. Software-in-the-Loop-Tests auf virtuellen Steuergeräten laufen davor und halten den Prüfstand für die Fälle frei, die echte Hardware brauchen. Die Regression läuft nachts über den Prüfstand, und wenn das Team morgens kommt, liegt der Report schon vor, statt dass jemand drei Tage lang Testfälle von Hand anstößt.
Signierte OTA-Updates und Nachweise
Die Pipeline signiert jedes OTA-Paket, rollt es in Wellen über A/B-Partitionen aus und protokolliert pro Fahrzeug, welcher Softwarestand mit welcher RxSWIN angekommen ist, wie es UNECE R156 für das Software-Update-Management verlangt. ASPICE-Prozessnachweise, die ISO-26262-Trace-Matrix und die Artefakte für ISO 21434 entstehen aus denselben Build-Daten.
Was bringt Automotive DevOps
messbar?
Welche Tools stecken in der
Pipeline?
Womit wir in diesem Umfeld arbeiten. Die Auswahl richtet sich nach der Toolchain, die bei Ihnen schon läuft, nicht nach unserer Präferenz.
CI/CD für Ihr Embedded-Projekt starten?
Lassen Sie uns sprechen. In einem kostenlosen Erstgespräch klären wir, wie wir Ihre spezifischen Herausforderungen lösen können.
Wie kommen ISO 21434
und UNECE R155/R156
in die Pipeline?
Jeder Build legt seine Nachweise als Artefakt ab, versioniert und mit dem Softwarestand verknüpft, aus dem sie stammen.
ISO/SAE 21434 und UNECE R155 verlangen ein Cybersecurity-Management über den gesamten Fahrzeuglebenszyklus, UNECE R156 ein nachvollziehbares Software-Update-Management mit RxSWIN. In der Pipeline wird daraus eine Reihe von Stages: TARA-Stand, SAST- und SCA-Befunde, SBOM und Signatur hängen an jedem Build, und jedes OTA-Paket trägt seinen Softwarestand. Dieselbe Pipeline erzeugt die Traceability vom Requirement bis zum Test, die ISO 26262 und ASPICE Level 2 und 3 fordern. Comquent baut solche CI/CD-Pipelines für Automotive, die Cybersecurity-Stages stützen sich auf unsere DevSecOps- & Compliance-Praxis.
AI- /01Automotive SPICE
Prozessreife für Tier-1-Verträge
Die Prozesse SWE.1 bis SWE.6 (von der Anforderung bis zur Verifikation) und SUP.8 (Konfigurationsmanagement) liegen als Pipeline-Artefakte vor: Trace-Matrix, Review-Protokolle, Coverage-Reports. Sie kommen aus dem Tooling, nicht aus PowerPoint, und das gilt unverändert für ASPICE 4.0.
- /02ISO 26262
Funktionale Sicherheit (ASIL A–D)
Sicherheitsanforderungen, Tool-Qualifikation, MISRA-C-Checks und ASIL-D-fähige Code-Coverage prüft die Pipeline in jeder Stage. Jeder Release bringt seinen Safety-Case mit.
- /03ISO 21434
Cybersecurity Management System (CSMS)
ISO-21434-Compliance heißt im Projektalltag, dass sich jedes Arbeitsprodukt der Norm, von der TARA über die Cybersecurity-Anforderungen bis zum Cybersecurity Case, einem konkreten Softwarestand zuordnen lässt. Die Pipeline legt dafür TARA-Updates pro Release, SAST- und SCA-Befunde, eine SBOM zu jedem Build, signierte Artefakte und den dokumentierten Umgang mit gemeldeten Schwachstellen als versionierte Artefakte ab. Wie tief sie prüft, richtet sich nach dem Cybersecurity Assurance Level (CAL) der Komponente, sofern das Projekt die CAL aus Anhang E der Norm verwendet. Yocto erzeugt die SBOM standardmäßig in SPDX 3.0 und gleicht sie seit 6.0 LTS mit sbom-cve-check gegen bekannte CVEs ab.
- /04UNECE R155 / R156
Software-Update-Management und RxSWIN
In der EU Pflicht für neue Fahrzeugtypen seit Juli 2022, für alle Neuzulassungen seit Juli 2024: signierte OTA-Pakete, RxSWIN-Tracking pro Steuergerät, ein vollständiges Software-Inventar und nachvollziehbare Rollback-Pfade, die mit der Flotte wachsen.
Was Automotive-Teams
wirklich fragen.
Vom Begriff über die Pipeline-Stufen und den Prüfstand bis zu den Normen, in der Reihenfolge, in der die Fragen im Projekt auftauchen.
- Q.01
- Was ist CI/CD für Automotive?
- CI/CD für Automotive überträgt Continuous Integration und Continuous Delivery auf sicherheitskritische Fahrzeug- und Embedded-Software: Jede Code-Änderung wird automatisch cross-kompiliert, auf realer Zielhardware per Hardware-in-the-Loop getestet und über signierte OTA-Prozesse ausgeliefert. Im Unterschied zur klassischen Web-CI/CD kommen qualifizierte Toolchains, ISO-26262-Traceability und ASPICE-Prozessnachweise hinzu. Die Pipeline erzeugt die Nachweiskette vom Requirement bis zum Test automatisch, statt dass sie Wochen vor dem Assessment aus Tickets, Mails und Build-Logs rekonstruiert wird.
- Q.02
- Worin unterscheidet sich CI/CD im Automotive von klassischem CI/CD?
- Klassisches CI/CD liefert Software auf Server und in Container aus; CI/CD im Automotive liefert auf Steuergeräte im Fahrzeug, mit qualifizierter Toolchain, Nachweispflicht und Typgenehmigung im Rücken. Drei Unterschiede prägen die Pipeline: Erstens läuft der Test nicht gegen einen Mock, sondern gegen reale Zielhardware am Hardware-in-the-Loop-Prüfstand. Das hebt Laufzeiten von Minuten auf Stunden und zieht eine Prüfstands-Warteschlange als Ressource in die Pipeline ein. Zweitens ist jede Stage nachweispflichtig: ISO 26262 verlangt die Trace-Kette vom Requirement bis zum Test, Automotive SPICE die Prozessartefakte, ISO 21434 die TARA, alles Nachweise, die eine Web-Pipeline nicht kennt. Drittens endet die Auslieferung nicht mit einem Rollout, sondern mit einem signierten OTA-Paket samt RxSWIN, Rollback-Pfad und Update-Log pro Fahrzeug nach UNECE R155/R156. Die Prinzipien bleiben dieselben: kleine Änderungen, schnelles Feedback, automatisierte Freigabe. Unterschiedlich sind Toolchain, Testinfrastruktur und Nachweisführung.
- Q.03
- Was ist Embedded DevOps?
- Embedded DevOps überträgt DevOps-Prinzipien auf die Entwicklung von Embedded-Software. CI/CD-Pipelines bauen, testen und verteilen Software für ressourcenbeschränkte Systeme wie Mikrocontroller, Steuergeräte (ECUs) und IoT-Geräte. Dazu gehören Cross-Compilation, Tests auf realer Hardware und OTA-Updates, die in einer herkömmlichen Web-Pipeline nicht vorkommen.
- Q.04
- Wie funktioniert CI/CD für Embedded-Systeme?
- CI/CD für Embedded-Systeme kompiliert jede Änderung automatisch für die Zielplattform, etwa mit Yocto oder Buildroot, testet sie auf Emulatoren und auf realer Hardware am HiL-Prüfstand und verteilt das fertige Image über einen OTA-Mechanismus. Zusätzlich prüft die Pipeline, was auf dem Server niemand misst: Speicherverbrauch, Timing und die Safety-Anforderungen des Zielsystems.
- Q.05
- Wie sieht eine CI/CD-Pipeline im Automotive aus?
- Eine CI/CD-Pipeline im Automotive durchläuft sechs Stufen: Commit und Cross-Compile (Yocto, Buildroot oder AUTOSAR-Build mit sstate-Cache), statische Analyse mit MISRA-C-Prüfung und SAST, Software-in-the-Loop-Tests auf virtuellen Steuergeräten (SIL), Hardware-in-the-Loop-Tests am Prüfstand mit realer Zielhardware (HiL), Nachweis-Erzeugung nach ISO 26262, ASPICE und ISO 21434 als Build-Artefakt und zuletzt das signierte OTA-Paket mit RxSWIN und Rollback-Pfad nach UNECE R155/R156. SIL fängt den Großteil der Fehler ab, bevor ein knapper Prüfstandsplatz belegt wird; HiL bleibt die Freigabestufe. Im Unterschied zu einer Web-Pipeline sind Prüfstand und Tool-Qualifikation feste Ressourcen in der Pipeline, nicht austauschbare Container.
- Q.06
- Welche Tools gehören in eine CI/CD-Pipeline für Embedded-Systeme?
- Eine CI/CD-Pipeline für Embedded-Systeme kombiniert Cross-Compile-Toolchains (Yocto, Buildroot, AUTOSAR-Builds), Versionskontrolle mit Git und Gerrit für Reviews, einen Build-Orchestrator wie Jenkins oder GitLab CI, Test-Frameworks (Unity, Google Test, HiL-Prüfstände), statische Analyse (SonarQube, Coverity), SBOM-Erzeugung (Syft, CycloneDX, bei Yocto auch das eingebaute SPDX 3.0), einen OTA-Update-Server und eine Artefakt-Registry wie Artifactory. Comquent baut solche Toolchains seit 2006 für Tier-1-Zulieferer und den OEM-nahen Mittelstand.
- Q.07
- Was ist Hardware-in-the-Loop-Testing?
- Hardware-in-the-Loop-Testing (HiL) verbindet die CI/CD-Pipeline mit realer Testhardware: Die Software läuft auf dem Zielsteuergerät, während der Prüfstand Sensorsignale und Umgebungsbedingungen simuliert. So fallen Integrationsprobleme auf, bevor die Software ins Fahrzeug kommt. Davor steht meist Software-in-the-Loop (SIL), der Test gegen ein virtuelles Steuergerät, der ohne knappe Prüfstandszeit auskommt und den Großteil der Fehler schon abfängt.
- Q.08
- Wie automatisiert man OTA-Updates?
- OTA-Updates (Over-the-Air) laufen über dieselbe Pipeline wie jeder andere Release: Build, Test, Signierung, Rollout in eine kleine Staging-Flotte und danach in die Breite. A/B-Partitionierung und automatischer Rollback sorgen dafür, dass ein fehlerhaftes Update das Steuergerät nicht lahmlegt, und Differential-Updates halten die Datenmenge klein.
- Q.09
- Was ist ISO 26262 im CI/CD-Kontext?
- ISO 26262 ist der Sicherheitsstandard für elektrische und elektronische Systeme in Straßenfahrzeugen. In der CI/CD-Pipeline heißt das: Jeder Build liefert den Nachweis der Testabdeckung, die Traceability zwischen Anforderungen und Tests, signierte Artefakte und die Dokumentation dazu, statt dass sie jemand vor dem Assessment zusammensucht.
- Q.10
- Welche Embedded-Lösungen unterstützen sicherheitskritische Anwendungen (ASIL/ISO 26262)?
- Für sicherheitskritische Anwendungen nach ISO 26262 (ASIL A bis D) kombiniert Comquent qualifizierte Toolchains mit einer durchgängig nachweisführenden CI/CD-Pipeline: Yocto- oder Buildroot-Builds mit reproduzierbaren Artefakten, MISRA-C-Prüfung, ASIL-D-fähige Code-Coverage, Tool-Qualifikation nach ISO 26262-8 und Hardware-in-the-Loop-Tests auf realer Zielhardware. AUTOSAR (Classic und Adaptive) sowie signierte OTA-Updates nach UNECE R155/R156 fügen sich in dieselbe Pipeline ein. Jeder Build liefert die Traceability-Kette vom Requirement bis zum Test und den Safety-Case automatisch mit, so bleibt die funktionale Sicherheit prüfbar, ohne den Release-Takt zu bremsen.
- Q.11
- Was ist ASPICE und wie unterstützt CI/CD die Konformität?
- Automotive SPICE (ASPICE) ist ein Prozessreifegradmodell für die Software-Entwicklung in der Automobilindustrie, und die meisten OEMs verlangen von ihren Zulieferern ein Assessment auf Level 2 oder 3. Eine CI/CD-Pipeline liefert einen großen Teil der Prozessnachweise nebenbei: den Anforderungs-Trace (SWE.1), die Reviews zum Architekturentwurf (SWE.2), die Unit-Verifikation (SWE.4), die Integrationstests (SWE.5) und das Konfigurationsmanagement (SUP.8). Die Prozesskennungen gelten so auch in der aktuellen Fassung ASPICE 4.0 weiter.
- Q.12
- Was bedeutet ISO 21434 für die CI/CD-Pipeline?
- ISO/SAE 21434 regelt das Cybersecurity Engineering über den gesamten Lebenszyklus eines Fahrzeugs und ist die übliche Grundlage für das Cybersecurity Management System (CSMS), das UNECE R155 für die Typgenehmigung verlangt. In der Pipeline heißt das: die Threat Analysis and Risk Assessment (TARA) als versioniertes Artefakt, Static Application Security Testing (SAST), Software Composition Analysis (SCA) für Drittkomponenten, eine SBOM zu jedem Build, signierte Artefakte und ein dokumentierter Prozess für gemeldete Schwachstellen. Yocto erzeugt die SBOM seit Release 5.1 (Oktober 2024) standardmäßig in SPDX 3.0; seit Yocto 6.0 LTS (Mai 2026) gleicht das eingebaute sbom-cve-check sie gegen bekannte CVEs ab, was einen Teil dieser Stage ohne Zusatzwerkzeug abdeckt.
- Q.13
- Wie erfüllt man UNECE R155 und R156 mit DevOps?
- UNECE R155 (Cybersecurity) und R156 (Software-Update-Management) gelten in der EU für neue Fahrzeugtypen seit Juli 2022 und für alle neu zugelassenen Fahrzeuge seit Juli 2024. Gefordert sind unter anderem signierte Update-Pakete, Software-Identifikationsnummern (RxSWIN), eine Aufzeichnung, welcher Softwarestand auf welchem Fahrzeug läuft, ein definiertes Verhalten bei fehlgeschlagenen Updates und ein nachvollziehbares Software-Inventar. Nach unserer Erfahrung ist das nur mit einer Pipeline wirtschaftlich zu leisten, die diese Nachweise pro Release erzeugt, denn von Hand gepflegte Listen halten mit einer wachsenden Flotte nicht Schritt.
- Q.14
- Warum scheitert die Einführung von CI/CD in der Automotive-Entwicklung häufig?
- CI/CD scheitert im Automotive selten an der Technik, sondern daran, dass Build-Zeit, Prüfstands-Zugang und Nachweisführung nicht gemeinsam gelöst werden. Drei Muster sehen wir regelmäßig. Die Pipeline wird um einen Yocto-Build gelegt, der weiterhin vier Stunden läuft, das Feedback kommt zu spät, und die Entwicklung weicht auf lokale Builds aus. Oder die HiL-Prüfstände bleiben manuell gebucht, sodass die Automatisierung genau dort endet, wo der eigentliche Test beginnt. Oder Compliance bleibt ein nachgelagerter Schritt, die Trace-Matrix entsteht weiter von Hand vor dem Assessment, und die Pipeline hat keinen Nachweiswert. Wer die drei Punkte zusammen angeht, also inkrementelle Builds mit sstate-Cache, Prüfstände als buchbare Pipeline-Ressource und Nachweise als Build-Artefakt, bekommt einen Release-Takt, der auch unter ASPICE trägt.
Vertiefen Sie
Embedded DevOps.
Praxisleitfäden, Referenzen und Tools rund um Industrial DevOps im Automotive- und Embedded-Umfeld.
Industrial DevOps
Unser Gesamtansatz: DevOps-Prinzipien für cyber-physische Systeme, SPS/PLC und Edge-Gateways.
ASIL-Level A bis D nach ISO 26262 erklärt
Was ASIL A, B, C und D bedeuten, wie die Einstufung über S/E/C zustande kommt und wie die Nachweise aus der Pipeline entstehen.
Automotive SPICE und das V-Modell
Was die ASPICE-Level bedeuten, was sich mit Version 4.0 geändert hat und welche Nachweise eine Pipeline liefert.
DevOps-Reifegrad-Check
In 3 Minuten erfahren, wo Ihr Embedded-DevOps steht und was als Nächstes ansteht.
Jenkins Pipeline Workshop & KI
Zwei Tage Praxis für Embedded-Teams: Pipelines, Shared Libraries und Tests, mit Claude Code im Terminal.
Jenkins Workshop mit KI: Admin & JCasC
Jenkins für Embedded-CI/CD professionell betreiben: Installation, Security-Hardening und Monitoring, KI-gestützt.