Entwicklung eingebetteter und sicherheitskritischer Software (MISRA, ISO 26262, IEC 62304)

Firmware für Fahrzeuge, Maschinen und Medizinprodukte muss nach Codierstandards geschrieben, von jeder Anforderung bis zu Code und Test zurückverfolgbar und durch Verifikationsnachweise belegt sein. Teams wenden einen großen Teil ihres Aufwands für diesen Papierkram und für das Beheben von Regelverstößen auf. LLM-Assistenten beschleunigen Entwürfe, MISRA-Korrekturen und die Pflege der Rückverfolgbarkeit, während deterministische Werkzeuge (Compiler, statischer Analysator, Tests) und qualifizierte Menschen die Freigabe behalten. Die KI schlägt vor; die Toolchain und der Sicherheitsingenieur entscheiden.

Problem & Nutzen

• Heute: Ingenieure schreiben C/C++ für ressourcenbeschränkte MCUs von Hand, lassen MISRA-Prüfer laufen, beheben Hunderte Befunde manuell, pflegen Rückverfolgbarkeitsmatrizen in ALM-Werkzeugen (ASPICE, ISO 26262-6, IEC 62304 §5) und stellen Nachweise für Assessoren zusammen. Nacharbeit spät im V-Modell ist teuer.
• KI-Nutzen: schnellere erste Entwürfe von Komponenten und Unit-Tests, automatisierte Behebung von Regelverstößen, Vorschläge für fehlende Trace-Links, Prüfung von Anforderungen auf Mehrdeutigkeit und erste Entwürfe von Arbeitsprodukten (Entwurfsbeschreibungen, Testspezifikationen), die Menschen verifizieren.
• Evidenz: Eine Studie von 2025 fand, dass keines der getesteten LLMs ungefragt MISRA-C++-konformen Code erzeugte, alle aber einzelne Verstöße auf Anweisung beheben konnten [10]; Woven by Toyota berichtet von einem Multi-Agenten-Prototyp „MISRA Copilot“, der 81,5 % der Verstöße in internem Code behob, wobei ein Mensch jede Korrektur freigibt (Herstellerangabe) [11]; und Forschungspipelines nutzen Retrieval auf Basis von ISO 26262/ASPICE, um aus Anforderungen Testspezifikationen zu entwerfen [12]. Veröffentlichte Zahlen schwanken je nach Aufbau und sind nicht verallgemeinerbar; messen Sie an Ihrer eigenen Codebasis.
• Harte Grenze: KI-Ausgabe ist nie für sich genommen ein Nachweis. Die Normen verlangen unabhängig verifizierte Arbeitsprodukte und, für Werkzeuge, deren Fehler unentdeckt bleiben könnten, Werkzeugvertrauen oder Qualifizierung (ISO 26262-8 Klausel 11, IEC 61508-3, DO-330).

Varianten

• Automobil (ISO 26262, ASPICE, AUTOSAR Classic/Adaptive, ISO/SAE 21434): Steuergeräte-Software, MISRA C:2012 / C++ (MISRA C++:2023), CERT.
• Software für Medizinprodukte (IEC 62304, MDR/IVDR): Lebenszyklus der Klassen A–C, Risikoakten (ISO 14971), Cybersicherheit (IEC 81001-5-1).
• Industrie / Maschinen (IEC 61508, ISO 13849; IEC 61131-3 steht in CODE-016): SIL-eingestufte Firmware, Antriebe, Sensoren.
• Bahn, Luftfahrt, Raumfahrt (EN 50128, DO-178C, ECSS): strengere Ziele; KI-Einsatz meist auf nicht anrechenbare Unterstützung beschränkt.
• KMU / Zulieferer: kleine Teams, die KI für Tests, MISRA-Bereinigung und Dokumentation nutzen, während der OEM den Prozess vorgibt.

So funktioniert es

1. Anforderungen / Sicherheitsziele (ALM)
2. KI-gestützte Verfeinerung (Mehrdeutigkeiten, Testbarkeit, fehlende Sicherheitsanforderungen)
3. Codeerzeugung / -änderung in IDE oder Agent (beschränkt auf freigegebene Vorlagen, Codierstandard im Prompt)
4. deterministische Prüfstellen: Compiler-Warnungen als Fehler, statische Analyse nach MISRA/CERT, formale Prüfungen / abstrakte Interpretation
5. KI-Korrekturschleife (Patch
6. Analysator erneut ausführen
7. nur akzeptieren, wenn Verstöße sinken und Tests bestehen)
8. Testerzeugung + Abdeckung (Anweisungs-/Zweig-/MC/DC) auf Host und Ziel / HIL
9. Rückverfolgbarkeit aktualisieren (Anforderung ↔ Code ↔ Test) mit KI-vorgeschlagenen Verknüpfungen
10. menschliches Review + unabhängige Verifikation + Freigabe durch den Sicherheitsmanager
11. Baseline und Nachweispaket

• Erzeugung: ein Code-LLM mit Retrieval über die Codierrichtlinien des Projekts, die HAL, die AUTOSAR-Konfiguration und vorhandene Module; die Ausgabe ist auf die Sprachteilmenge beschränkt (keine dynamische Speicherallokation, keine Rekursion, begrenzte Schleifen).
• Geschlossene Schleife mit Analysatoren: Der Analysatorbericht wird an das Modell zurückgegeben; ein Patch wird nur akzeptiert, wenn Analysator und Testsuite ihn bestätigen. So lassen sich halluzinierte „Korrekturen“ erkennen.
• Rückverfolgbarkeit: Embeddings + LLM schlagen Verknüpfungen vor und markieren verwaiste Anforderungen oder ungetesteten Code; Menschen bestätigen.
• Mensch-in-der-Schleife (Human-in-the-Loop): gesamtes Code-Review, Freigabe von Abweichungen (MISRA-Abweichungsdokumentation), Schlussfolgerungen der Sicherheitsanalyse (FMEA/FTA/HARA) und Release-Freigabe.

Datenaufbereitung

Die Aufbereitung ist mittelgroß (grob 25 bis 35 Prozent des Aufwands) und besteht überwiegend darin, Anforderungen, Code und Nachweise maschinenlesbar zu machen. Die Daten liegen in ALM-Werkzeugen (DOORS, Polarion, Jira), Git oder SVN, Word- und Excel-Anforderungsdokumenten, Berichten der statischen Analyse, Test- und Coverage-Ergebnissen sowie auf Netzlaufwerken mit Abweichungsdokumentation und Sicherheitsanalysen. Typische Lücken: Anforderungen in Dokumenten ohne IDs, defekte oder fehlende Rückverfolgbarkeitsverknüpfungen, MISRA-Abweichungen als Freitext, uneinheitliche Werkzeugversionen und Regelwerke, gescannte Review-Protokolle und Wissen über die HAL oder die AUTOSAR-Konfiguration in wenigen Köpfen.

Schritte zur Aufbereitung: - Exportieren Sie Anforderungen mit stabilen IDs (ReqIF oder API; PREP-005) und wandeln Sie dokumentbasierte in strukturierte Einträge um (DOC-014, PREP-007). - Legen Sie Regelwerk, Compiler- und Analysatorversionen fest, damit Ergebnisse reproduzierbar sind. - Strukturieren Sie Abweichungsdokumentation und Review-Entscheidungen als Tabellen mit Regel, Begründung und Freigebendem (PREP-011, PREP-020). - Sammeln Sie Musterlösungsmodule und frühere Korrektur-Patches als Beispiele und Evaluationssatz (PREP-016, PREP-018). - Schreiben Sie die Codierrichtlinie und die HAL-Konventionen als kurze, abrufbare Dokumente (PREP-013, PREP-014). - Stufen Sie Code nach Vertraulichkeit und vertraglichen Einschränkungen ein (PREP-024).

Prüfen Sie mit GUIDE-003 die Reife vor dem Pilot.

Umsetzungswege

Welcher Weg für wen

• enterprise: Weg C — OEM-Verträge und Exportkontrolle verbieten oft, sicherheitsrelevanten Code an Clouds zu senden, gemeinsame Werkzeuge über Projekte hinweg rechtfertigen HW3-Hosting, und die analysatorgesteuerte Schleife funktioniert mit Open-Weight-Modellen.
• developer: Weg B — ein Coding-Agent, der über MCP mit clang-tidy, Cppcheck und Tests verbunden ist, liefert für nicht vertraulichen Code schnell eine funktionierende Korrekturschleife.
• smb: Weg B — Zulieferer und Gerätehersteller brauchen projektspezifische MISRA- und Rückverfolgbarkeits-Pipelines, die kein Produkt vollständig abdeckt; nutzen Sie APIs in EU-Regionen mit Bedingungen ohne Datenspeicherung und halten Sie OEM-vertrauliche Module heraus, oder wechseln Sie zu Weg C, falls der Vertrag es verlangt.

Weg A — Kaufen (Standardsoftware)

• Assistenten mit sicherheitsbewussten Funktionen: GitHub Copilot, Cursor, Claude Code, Kiro (Nachfolger von Amazon Q Developer), JetBrains AI, eingesetzt nach Unternehmensrichtlinie; Hersteller für Embedded-Entwicklung integrieren KI in etablierte Toolchains.
• Hersteller statischer Analyse mit KI-Unterstützung: Perforce Helix QAC und Klocwork, Parasoft C/C++test (KI-gestützte Tests und Korrekturen), Synopsys Coverity, MathWorks Polyspace (Bug Finder / Code Prover), LDRA, TrustInSoft (EU), Vector Informatik (EU) mit VectorCAST, Axivion (EU, Qt Group), Werkzeuge von Bosch/ETAS, Siemens Polarion und Jama/Codebeamer (PTC) für die ALM-Rückverfolgbarkeit.
• Wählen Sie A, wenn: Sie vom Hersteller qualifizierte Werkzeuge und einen prüfbaren Prozess wünschen; KI-Funktionen sind Zusätze rund um eine bestehende zertifizierte Kette.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Spitzen-Code-Modelle (Claude, GPT, Gemini) oder EU-Anbieter (Mistral Codestral) über EU-Regionen; Orchestrierung mit einem Agenten-Framework, das Ihren Analysator, Compiler, Simulator und die ALM-APIs über MCP oder Skripte aufruft.
• Muster: Das Modell sieht unveröffentlichtes sicherheitskritisches IP nur, wenn Verträge und Exportkontrollregeln es erlauben; nutzen Sie Endpunkte in EU-Regionen und Bedingungen ohne Datenspeicherung.
• Wählen Sie B, wenn: Sie eine projektspezifische Korrektur- oder Rückverfolgbarkeits-Pipeline brauchen und keine strikte Netztrennung (Air-Gap) verlangt ist.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Code-Modelle: Qwen3-Coder, DeepSeek-Coder-Familie, offene Codestral-Varianten, Granite-Code-Modelle (IBM), bereitgestellt mit vLLM oder Ollama; IDE-Integration über Continue oder Cline.
• Stack: clang-tidy, Cppcheck (MISRA-Addon), GCC-/Clang-Warnungen, Frama-C, CBMC, Unity/Ceedling oder GoogleTest, Simulation mit Renode/QEMU, Eclipse-SCA-Werkzeuge, Sphinx-needs / StrictDoc / OpenFastTrace für die Rückverfolgbarkeit.
• Hardware: HW3 für Code-Modelle mit 30–120B für Zulieferer mit IP- oder Air-Gap-Vorgaben; HW2 genügt für kleinere Modelle mit der Korrekturschleife.
• Wählen Sie C, wenn: OEM-Verträge die Übertragung von Code in die Cloud verbieten.

Weg D — Eigenes Training

Feintuning auf Ihrem eigenen MISRA-konformen Code und früheren Abweichungsentscheidungen kann die Korrekturqualität für Ihren Dialekt, Compiler und Ihre HAL verbessern. Nötig sind Tausende geprüfter Vorher-nachher-Patches; nutzen Sie den Analysator als automatisches Belohnungssignal.

Stand der Technik (2026)

• Agenten mit Analysator in der Schleife sind das funktionierende Muster: Reine Erzeugung produziert Regelverstöße; verifizierte Korrekturschleifen sind weit zuverlässiger als einmalige Prompts.
• Formale und beschränkte Prüfungen (Frama-C, CBMC, Polyspace) lassen sich mit von LLMs geschriebenen Annotationen oder Verträgen kombinieren; Korrektheitsbeweise brauchen weiterhin die Prüfung durch Experten.
• Testerzeugung aus Anforderungen für Arbeitsprodukte nach ASPICE SWE.1-SWE.6 ist ein aktives Feld in Forschung und bei Herstellern [6].
• Normen im Wandel: MISRA C++:2023 bündelte die C++-Leitlinien; ISO/IEC TS 22440 (funktionale Sicherheit und KI-Systeme) und ISO/PAS 8800 (Straßenfahrzeuge, Sicherheit und KI) behandeln KI in Produkten, nicht KI als Entwicklungswerkzeug, prägen aber das Denken zum Werkzeugvertrauen [4].
• Grenzen / Fehlerbilder: subtiles undefiniertes Verhalten, Fehler bei Integer-Promotion, Verletzungen von Timing und WCET, falsche Semantik von Hardware-Registern, halluzinierte HAL-Funktionen und übertrieben sichere Sicherheitsbegründungen. Tests auf dem Host beweisen nicht das Verhalten auf dem Zielsystem. LLMs sind nichtdeterministisch, was die Werkzeugqualifizierung erschwert; behandeln Sie sie als unqualifizierte Vorschlagsmaschinen, deren Ausgabe durch qualifizierte Werkzeuge verifiziert wird.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: CODE-001/002 (Assistenten und Agenten), CODE-003 (Review), CODE-004 (Testerzeugung), CODE-006 (Dokumentation), CODE-014 (Fehlertriage), CODE-005 (Modernisierung von Alt-C-Code), SEC-004 (sicheres Code-Scanning und automatische Korrektur; ISO/SAE 21434 und CRA), CODE-016 (SPS-Code), CODE-019 (RTL-/Chip-Verifikation), ROBO-016 (KI in Maschinensicherheitsfunktionen).
• Gemeinsam genutzt: Code-LLM-Server (HW2/HW3), Embedding-Index über Anforderungen und Code, CI-Runner mit Analysatoren, ALM-Integration.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen, um KI-Funktionen in einer vorhandenen Toolchain zu aktivieren; Lizenzkosten pro Arbeitsplatz.
• Weg B: 2–4 Monate für eine Pipeline zur Korrektur und Rückverfolgbarkeit samt Prozessdokumentation.
• Weg C/D: 4–9 Monate; GPU-Server, MLOps und Integration in den Sicherheitsprozess.
• Haupt-Kostentreiber: Argumentation zum Werkzeugvertrauen, Abstimmung mit Assessoren, Integration mit ALM und CI, Prüfaufwand.
• Kennzahlen: behobene MISRA-Verstöße pro Woche und Quote akzeptierter Patches, Prüfzeit je Änderung, durchgerutschte Fehler, Rückverfolgbarkeitsabdeckung, Testabdeckung (MC/DC, wo gefordert), Nacharbeitsquote in späten Phasen, Befunde der Assessoren.

Menschen & Veränderung

• Einbinden: Geschäftsleitung (Haftung, Werkzeugbudget), den Entwicklungsleiter als Prozesseigner, Entwickler, Tester und den Sicherheitsbeauftragten als tägliche Nutzer, Qualitätsmanagement und Recht für Argumente zum Werkzeugvertrauen nach ISO 26262 oder IEC 62304 und für Verträge, die IT-Sicherheit für den Codeschutz sowie Zulieferer oder OEMs, deren Vertraulichkeitsbedingungen einschränken, was das Modell sehen darf.
• Betriebsrat: abhängig. Der Assistent analysiert Code, doch IDE- und Agenten-Logs sowie Akzeptanzkennzahlen je Entwickler können die Leistung überwachen; dann gilt § 87 Abs. 1 Nr. 6 BetrVG. Informieren Sie den Betriebsrat rechtzeitig nach § 90 Abs. 1 Nr. 3 BetrVG und erwägen Sie einen Sachverständigen nach § 80 Abs. 3 für eine Betriebsvereinbarung zu KI-Werkzeugen.
• Datenschutz: überwiegend keine personenbezogenen Daten; Ausnahme sind Entwicklerkennungen in Logs. Beziehen Sie den/die Datenschutzbeauftragte(n) kurz ein und schließen Sie einen AVV (Art. 28 DSGVO) mit den Anbietern. Eine DSFA ist normalerweise nicht nötig.
• KI-Kompetenz: Unterstützen Sie Entwickler mit Schulungen zu typischen Halluzinationen in C/C++ und dazu, warum die Ausgabe des Analysators und nicht das Modell entscheidet (Art. 4 KI-Verordnung in der geänderten Fassung).
• Pilot und Kommunikation: Beginnen Sie mit MISRA-Korrekturen an einem unkritischen Modul, geprüft von einem erfahrenen Ingenieur.
• Bedenken: „KI-generierter Code ist nicht zertifizierbar“ — antworten Sie mit denselben Review- und Verifikationsnachweisen wie für menschlichen Code und einer dokumentierten Richtlinie zur Werkzeugnutzung.
• Menschen behalten die Kontrolle: Abweichungen, Sicherheitsbegründung und Release-Freigabe bleiben bei qualifizierten Personen.

Siehe GUIDE-007, GUIDE-008 und GUIDE-014.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das Entwicklungswerkzeug selbst hat typischerweise minimales Risiko (Pflicht zur KI-Kompetenz, Art. 4). Das Produkt kann ein Hochrisiko-System sein: Sicherheitsbauteile von Produkten nach den harmonisierten Rechtsvorschriften in Anhang I (Maschinen, Medizinprodukte usw.) fallen unter Art. 6 Abs. 1; typgenehmigte Fahrzeuge werden über sektorale Vorschriften erfasst. Keine verbotene Praxis nach Art. 5.
• Sektorregeln: ISO 26262 (einschließlich Werkzeugvertrauen, Teil 8), ASPICE 4.0, IEC 62304 und MDR/IVDR, IEC 61508, UNECE R155/R156 für Cybersicherheit und Updates, EU-Cyberresilienzgesetz (Cyber Resilience Act) und die neue Maschinenverordnung (EU) 2023/1230 für Software-Sicherheitsfunktionen [2][3].
• Haftung: Der Hersteller bleibt verantwortlich; KI-Vorschläge brauchen dieselbe Prüfung wie Code von Nachwuchsingenieuren.
• IP und Exportkontrolle: Senden Sie proprietären oder OEM-vertraulichen Code nicht ohne vertragliche Freigabe an APIs; die DSGVO ist weitgehend irrelevant, außer bei Entwickleridentitäten und Logs.
• Gegenmaßnahmen: Prüfschritte durch Analysator und Tests, unabhängiges Review, keine KI-generierte Sicherheitsbegründung ohne Expertenprüfung, protokollierte Prompts und Ausgaben, dokumentierte Richtlinie zur Werkzeugnutzung und Bewertung des Werkzeugvertrauens, eingeschränkte Code-Teilmengen.

Erste Schritte

1. Vereinbaren Sie mit dem Sicherheitsbeauftragten und dem Assessor eine Richtlinie zur KI-Nutzung: erlaubte Tätigkeiten, Einstufung des Werkzeugvertrauens, Prüfregeln.
2. Beginnen Sie mit risikoarmen Aufgaben: MISRA-Bereinigung in unkritischen Modulen, Entwürfe für Unit-Tests, Dokumentation, jeweils mit Analysator-Prüfschritt.
3. Bauen Sie die geschlossene Schleife (Patch → statische Analyse → Tests → menschliche Prüfung) in der CI auf und messen Sie die Akzeptanzquote.
4. Ergänzen Sie Rückverfolgbarkeitsvorschläge in Ihrem ALM-Werkzeug; verfolgen Sie die Präzision der vorgeschlagenen Verknüpfungen.
5. Führen Sie einen Pilot an einer Komponente durch, prüfen Sie ihn mit Ihrem Assessor und skalieren Sie dann.

Quellen

1. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj
3. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
4. ISO 26262-1:2018 Road vehicles, functional safety — https://www.iso.org/standard/68383.html
5. MISRA — Guidelines and compliance resources — https://misra.org.uk/
6. Automotive SIG — Automotive SPICE process assessment model — https://vda-qmc.de/en/automotive-spice/
7. IEC 62304:2006+A1:2015 Medical device software lifecycle — https://www.iso.org/standard/71604.html
8. Frama-C project — https://frama-c.com/
9. CBMC bounded model checker — https://github.com/diffblue/cbmc
10. Umer — Comparative analysis of LLM-generated code for MISRA C++ compliance (arXiv 2506.23535) — https://arxiv.org/abs/2506.23535
11. Woven by Toyota — Agentic AI for a zero-accident future (MISRA Copilot proof of concept) — https://www.woven.toyota/en/news/agentic-ai-for-a-zero-accident-future
12. Cluster-aware dual-level test specification generation for large-scale automotive software requirements (arXiv 2606.17197) — https://arxiv.org/abs/2606.17197