LLMs und MISRA-konformer C-Code: Grenzen und Freigabe

LLMs und MISRA-konformer C-Code: Grenzen und Freigabeprozess

KI-generierter C-Code darf in Serienprojekte einfließen, wenn er denselben Freigabeprozess durchläuft wie menschlich geschriebener Code: statische Analyse gegen das projektspezifische MISRA-Regelwerk, verpflichtendes Review durch den verantwortlichen Entwickler und Freigabe über den bestehenden Merge-Prozess mit lückenloser Traceability. Ein Sprachmodell (Large Language Model, LLM) liefert dabei belastbare Muster, Boilerplate und Refactoring-Vorschläge. Es stellt jedoch keine MISRA-Konformität sicher, weil ihm das Projektregelwerk, die Toolchain-Eigenheiten und der Deviation-Prozess fehlen. Der KI-Vorschlag ist ein Entwurf, kein freigegebenes Arbeitsprodukt. sensified ordnet Code-Assistenz in die Triage-Klassen A2 und B ein und beschreibt den Freigabepfad, der sie assessierbar hält.

Die Situation ist in vielen Steuergeräte-Projekten dieselbe. Ein Entwickler zeigt im Team-Meeting einen Zustandsautomaten, den ein Sprachmodell in einem Bruchteil der üblichen Zeit entworfen hat, und die Frage steht im Raum: Darf so etwas in die Serie? Wer als Software-Verantwortlicher antworten muss, braucht zwei Dinge: ein realistisches Bild davon, was ein LLM gegenüber einem Regelwerk wie MISRA tatsächlich leistet, und einen Freigabeprozess, der die Lücken systematisch schließt. Beides liefert dieser Beitrag. Er ist Teil der Werkzeug-Ebene, deren Überblick der Beitrag zu KI in der Automotive-Softwareentwicklung gibt. Eine Einordnung vorweg: Die Eignungsaussagen sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Was MISRA-Konformität im Serienprojekt bedeutet

Bevor sich beurteilen lässt, was ein Sprachmodell zur Konformität beiträgt, lohnt der Blick auf das, was Konformität formal verlangt. MISRA C ist kein Stilratgeber. In den meisten Steuergeräte-Projekten ist das Regelwerk vertraglich oder prozessual als Freigabe-Voraussetzung verankert, und die Einhaltung wird gegenüber Kunde und Assessor nachgewiesen.

Regeln, Direktiven und drei Kategorien

MISRA C:2023 umfasst 221 Guidelines, davon 200 Regeln und 21 Direktiven, und deckt die Sprachstände von C90 bis C18 ab; mit MISRA C:2025 liegt inzwischen eine Folgeausgabe vor. Regeln sind so formuliert, dass ein statisches Analysewerkzeug ihre Einhaltung prüfen kann. Direktiven adressieren dagegen Prozess- und Dokumentationsanforderungen, etwa den dokumentierten Umgang mit implementierungsabhängigem Verhalten; Werkzeuge können hier nur unterstützen, das Urteil bleibt beim Menschen. Quer dazu liegt die Kategorisierung: Mandatory-Guidelines sind ohne Ausnahme einzuhalten, für Required-Guidelines sind dokumentierte Abweichungen in begründeten Ausnahmefällen zulässig, Advisory-Guidelines sind Empfehlungen mit niedrigerer Deviation-Hürde. Viele Projekte rekategorisieren zudem: Sie stufen einzelne Advisory-Guidelines auf Required hoch oder legen projektspezifische Prüfschärfen fest. Genau diese Projektschicht ist für die LLM-Frage entscheidend, denn sie steht in keinem Trainingsdatensatz.

Deviations: geordnete Abweichung mit Nachweis

Der zweite formale Baustein ist der Deviation-Prozess. Das Dokument MISRA Compliance:2020 (Herausgeber: MISRA) beschreibt, wie ein Projekt trotz einzelner Regelverletzungen konform bleiben kann: über autorisierte Deviation-Records, die unter anderem die verletzte Guideline, die Umstände der Abweichung, die Begründung, den fachlichen Hintergrund sowie Risikobewertung und Vorkehrungen festhalten. Für wiederkehrende Use-Cases gibt es Deviation-Permits, und die Guideline Compliance Summary dokumentiert je Guideline den Konformitätsstand des Projekts. Wichtig für die Einordnung von KI-Werkzeugen: Eine Deviation ist ein organisatorischer Vorgang mit Begründungspflicht und Autorisierung. Ein Sprachmodell kann eine Deviation weder beantragen noch verantworten; es kann höchstens Textbausteine für die Begründung vorbereiten, die der Verantwortliche prüft.

Was ein LLM an MISRA-Konformität real leistet

Die ehrliche Bestandsaufnahme fällt zweigeteilt aus. Es gibt Muster, in denen Sprachmodelle die Arbeit an konformem C-Code spürbar unterstützen, und es gibt eine Grenze, die sich mit besseren Modellen verschiebt, aber nicht verschwindet.

Drei tragfähige Muster

Erstens Boilerplate und Schema-Arbeit: Zustandsautomaten nach vorgegebenem Muster, Treiber- und Modul-Gerüste, Unit-Test-Gerüste, Kommentierung. Wird das Modell mit einem konformen Referenzmuster aus dem eigenen Codebestand angeleitet, vermeidet der Entwurf viele der üblichen Verstöße von vornherein, etwa implizite Typumwandlungen oder unsaubere Kontrollflüsse. Zweitens Refactoring-Vorschläge entlang von Analyse-Findings: Das statische Analysewerkzeug meldet einen Verstoß, das Modell erhält Finding und Codeausschnitt und schlägt eine konforme Umformulierung vor, die der Entwickler prüft und übernimmt oder verwirft. Drittens Erklärarbeit: Das Modell macht die Intention einer Guideline verständlich, fasst zusammen, warum eine Konstruktion problematisch ist, und bereitet Reviews vor, indem es Diffs verdichtet und Auffälligkeiten vorsortiert. Die ersten beiden Muster sind vorbereitende Automatisierung mit Prüfpunkt, das dritte ist rein lesende Unterstützung.

Warum das kein Konformitätsnachweis ist

Ein Sprachmodell erzeugt statistisch plausiblen Text. Es kann Code produzieren, der konform aussieht, weil er den Oberflächenmerkmalen konformen Codes ähnelt. Konformität ist aber eine nachgewiesene Eigenschaft gegenüber einem konkreten Regelwerk, einer konkreten Toolchain und einem konkreten Prüfprozess. Der Unterschied zwischen konform aussehen und konform sein wird ausschließlich durch statische Analyse und Review geschlossen, für KI-Vorschläge genauso wie für menschlich geschriebenen Code. Wer dem Modell den Nachweis überlässt, hat keinen Nachweis.

Wo Sprachmodelle systematisch scheitern

Die Grenzen sind keine Frage der Modellgüte allein. Sie folgen aus der Struktur der Aufgabe: MISRA-Konformität hängt an Wissen, das außerhalb des Prompts liegt.

Projektregelwerk und Kontextwissen

Das erste systematische Defizit ist das projektspezifische Regelwerk. Rekategorisierte Guidelines, projektintern verschärfte Prüfkonfigurationen, hausinterne Codier-Richtlinien, Namens- und Architektur-Konventionen aus zwanzig Jahren Codegeschichte: All das prägt, was in Ihrem Projekt als konform gilt, und nichts davon kennt ein allgemein trainiertes Modell. Selbst wenn die Richtlinien in den Kontext gegeben werden, bleibt die Anwendung unsicher, weil das Modell Prioritäten und Ausnahmen nicht verlässlich gegeneinander abwägt. Die Folge sind Vorschläge, die gegen das Basis-Regelwerk bestehen würden und trotzdem im projekteigenen Prüfprofil durchfallen.

Undefined Behavior, Toolchain und Deviation-Prozess

Das zweite Defizit liegt in der Sprache C selbst. Undefiniertes Verhalten entsteht oft aus unscheinbaren Konstruktionen: Integer-Promotion in Ausdrücken mit gemischten Typen, Auswertungsreihenfolgen, Aliasing-Annahmen. Ein Modell reproduziert hier auch Fehlmuster aus seinen Trainingsdaten, und gerade die subtilen Fälle sehen für Mensch und Modell harmlos aus. Hinzu kommen Toolchain-Eigenheiten: Compiler-Erweiterungen, Intrinsics, Memory-Map und Linker-Konfiguration des Zielsystems, Eigenheiten des eingesetzten Analysewerkzeugs. Und schließlich der Deviation-Prozess: Ob eine Abweichung vertretbar ist, welche Risikobewertung sie braucht und wer sie autorisiert, ist eine organisatorische Entscheidung im Projekt. Sie lässt sich delegieren an Rollen, nicht an Modelle.

Der Freigabeprozess, der KI-Vorschläge trägt

Aus Leistungen und Lücken folgt der Prozess. Er ist bewusst unspektakulär, denn er besteht fast vollständig aus Stationen, die ein geordnetes Serienprojekt ohnehin hat. Neu ist nur die konsequente Behandlung des KI-Vorschlags als Entwurf.

Fünf Stationen vom Vorschlag zum Merge

Erste Station: Der KI-Vorschlag entsteht als Entwurf im Arbeitsbereich des Entwicklers und erreicht von sich aus keinen geteilten Stand. Zweite Station: Review-Pflicht. Der verantwortliche Entwickler prüft den Vorschlag fachlich, mit derselben Sorgfalt wie fremden Code, denn genau das ist er. Dritte Station: statische Analyse gegen das MISRA-Regelwerk in der projektspezifischen Konfiguration, ohne Sonderpfad und ohne Ausnahme für KI-Anteile. Vierte Station: der bestehende Merge-Prozess mit Vier-Augen-Review, Pipeline-Gates und dokumentierter Freigabe. Fünfte Station: Traceability. Die Änderung bleibt der Anforderung zugeordnet, der Freigabepunkt ist dokumentiert, und die KI-Unterstützung ist je Commit oder Change-Request gekennzeichnet, damit die Herkunft in Audits und Assessments beantwortbar bleibt.

Tool-Vertrauen und Nachweisführung

Zwei Ergänzungen machen den Prozess assessierbar. Zum einen die Werkzeug-Frage: Sobald ein KI-Assistent Einfluss auf sicherheitsrelevante Arbeitsprodukte nimmt, gehört er in die Tool-Vertrauensbetrachtung nach ISO 26262, wie jedes andere Werkzeug der Kette. Die Argumentation fällt hier vergleichsweise gut, weil der Prozess jeden Fehler des Werkzeugs durch nachgelagerte Prüfungen abfängt: Review und statische Analyse stehen zwischen Vorschlag und Arbeitsprodukt. Zum anderen die Nachweisführung insgesamt. Wie eng es auf dieser Strecke bereits ohne KI zugeht, zeigt eine Selbstauskunfts-Zahl der Branche: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Ein KI-Baustein, der Code beschleunigt und die Nachweiskette schwächt, verschlechtert die Gesamtlage. Ein Baustein, der Entwürfe liefert und die Kette unangetastet lässt, verbessert sie.

Triage-Einordnung: Klasse A2 und Klasse B

Im Vorgehensmodell von sensified wird jede KI-Fähigkeit einer Triage-Klasse zugeordnet, und für die Code-Assistenz im MISRA-Kontext sind zwei Klassen einschlägig. Vorschlags-Arbeit, also Boilerplate, Implementierungsentwürfe und Refactoring-Vorschläge, ist Klasse A2: vorbereitende Automatisierung mit Prüfpunkt beim Menschen. Erklär- und Analysearbeit, also Guideline-Erläuterungen, Code-Verständnis und Review-Vorbereitung, ist Klasse B: rein lesende Augmentation ohne eigenen Arbeitsstand. Autonome Fallabwicklung, Klasse C, etwa das ungeprüfte Einpflegen von Fixes bis in den Merge, startet grundsätzlich als nicht zulässig und würde nur nach expliziter Prüfung geöffnet; im MISRA-Kontext ist ein solcher Schritt auf absehbare Zeit nicht begründbar. Der rote Faden bleibt über alle Klassen derselbe: KI assistiert, der Mensch verantwortet. Die vollständige Logik hinter den Klassen beschreibt der Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering.

Einführung im Team: vor dem ersten Serien-Commit

Der Prozess auf dem Papier ist die halbe Strecke. Die andere Hälfte ist die geordnete Einführung: ein Pilot mit klar umrissenem Scope, eine Regelung, welche Code- und Kontextdaten das Haus verlassen dürfen, eine Kennzeichnungs-Konvention für KI-gestützte Änderungen und eine ehrliche Erwartungssteuerung im Team. Erfahrene Embedded-Entwickler prüfen ein neues Werkzeug zu Recht kritisch; die Akzeptanz entsteht dort, wo das Werkzeug lästige Schema-Arbeit übernimmt und die Urteilsarbeit sichtbar beim Entwickler bleibt. Fragen zu IP-Schutz, Konformitätsrahmen und Pilot-Design behandelt der Beitrag zur Einführung von KI-Coding-Assistenten im Embedded-Team. Für den MISRA-Kontext gilt zusätzlich: Das Prüfprofil der statischen Analyse und die Deviation-Praxis des Projekts gehören in die Pilot-Definition, damit der Pilot unter Serienbedingungen misst und keine Demo-Ergebnisse produziert.

Nächste Schritte

Ob Code-Assistenz in Ihrem Projekt zuerst als Erklärwerkzeug, als Refactoring-Hilfe oder als Entwurfsgenerator trägt, hängt von Toolchain, Regelwerk-Konfiguration und Teamlage ab und lässt sich nicht pauschal entscheiden. Der geordnete Einstieg sieht so aus:

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage im Zusammenhang.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Werkzeug-Bausteinen ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Scope, Toolchain und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zu Sprachmodellen und MISRA-konformem C-Code zusammen. Sie beschreiben typisierte Muster und Freigabepfade; wie die Lage in einem konkreten Projekt ist, wird je Kunde und Toolchain geprüft.

Darf KI-generierter C-Code in ein MISRA-Serienprojekt einfließen?

Ja, unter denselben Bedingungen wie jeder andere Code: statische Analyse gegen das projektspezifische MISRA-Regelwerk, verpflichtendes Review durch den verantwortlichen Entwickler und Freigabe über den bestehenden Merge-Prozess mit dokumentierter Traceability. Der KI-Vorschlag ist ein Entwurf, kein freigegebenes Arbeitsprodukt. Ein Sonderpfad an der Prüfkette vorbei ist in keinem Fall zulässig.

Kann ein LLM MISRA-konformen C-Code sicherstellen?

Nein. Ein Sprachmodell erzeugt statistisch plausiblen Code, der konform aussehen kann, ohne es zu sein. Konformität ist eine nachgewiesene Eigenschaft gegenüber dem konkreten Regelwerk, der Toolchain und dem Prüfprofil des Projekts, und dieser Nachweis entsteht ausschließlich durch statische Analyse und menschliches Review.

Ersetzt ein LLM die statische Analyse?

Nein, die beiden Werkzeuge liegen an verschiedenen Stellen der Kette. Das Sprachmodell liefert Entwürfe und Umbauvorschläge vor der Prüfung, das statische Analysewerkzeug erbringt den Konformitätsnachweis nach dem Entwurf. Sinnvoll kombiniert werden sie, indem Analyse-Findings als Eingabe für Refactoring-Vorschläge dienen, die der Entwickler prüft.

Wie funktioniert der Deviation-Prozess bei KI-generiertem Code?

Genauso wie bei menschlich geschriebenem Code, nach MISRA Compliance:2020: Eine Abweichung von einer Required-Guideline braucht einen autorisierten Deviation-Record mit Begründung, Risikobewertung und Vorkehrungen. Ein Sprachmodell kann Textbausteine für die Begründung vorbereiten, die Bewertung und Autorisierung bleiben beim verantwortlichen Menschen. Mandatory-Guidelines erlauben grundsätzlich keine Deviation.

Muss ein KI-Coding-Assistent nach ISO 26262 betrachtet werden?

Ja, sobald er Einfluss auf sicherheitsrelevante Arbeitsprodukte nimmt, gehört er in die Tool-Vertrauensbetrachtung nach ISO 26262 wie jedes andere Werkzeug der Kette. Die Argumentation stützt sich üblicherweise darauf, dass Review und statische Analyse als nachgelagerte Prüfungen jeden Werkzeugfehler abfangen. Diese Prüfungen müssen dafür verbindlich und dokumentiert sein.

Wie bleibt Traceability erhalten, wenn KI-Vorschläge einfließen?

Jede Änderung bleibt der auslösenden Anforderung oder dem Change-Request zugeordnet, der Freigabepunkt ist dokumentiert, und KI-Unterstützung wird je Commit oder Change-Request gekennzeichnet. Damit bleibt in Audits und Assessments beantwortbar, wer was wann freigegeben hat und welche Anteile mit Werkzeug-Unterstützung entstanden sind. Riskant ist der umgekehrte Fall: unmarkierte KI-Anteile in Arbeitsprodukten.

Welche Triage-Klasse hat Code-Assistenz im MISRA-Kontext?

Vorschlags-Arbeit wie Boilerplate, Implementierungsentwürfe und Refactoring-Vorschläge ist Klasse A2, also vorbereitende Automatisierung mit Prüfpunkt beim Menschen. Erklär- und Analysearbeit wie Guideline-Erläuterungen und Review-Vorbereitung ist Klasse B, also rein lesende Augmentation. Autonome Fallabwicklung bis in den Merge, Klasse C, startet als nicht zulässig.