Coding Agents in der Fahrzeugentwicklung: Was ASPICE und ISO 26262 verlangen

Ein selbst gebautes CI-Gate, dessen Ergebnis ungeprüft über Pass oder Fail entscheidet, kann in den Anwendungsbereich der Werkzeugqualifizierung fallen. Bei einem Agentenvorschlag, dessen relevante Ausgabe für den betreffenden Prozessschritt nach einem festgelegten und dokumentierten Verfahren geprüft oder verifiziert wird, kann die Einstufung anders ausfallen. Entscheidend sind der konkrete Prozessschritt, die Wirkung der Ausgabe und die vorgesehenen Erkennungsmaßnahmen.

Wer im Kundenassessment erklären muss, wie generative Werkzeuge in die eigene Nachweiskette eingebunden sind, muss mehrere Regelwerke auseinanderhalten.

Dieser Text ist eine fachliche Einordnung anhand der genannten Quellen. Er ist kein Rechtsrat und ersetzt weder die projektbezogene Werkzeugbewertung noch ein Assessment.

Kurz gefasst: Ob eine Werkzeugqualifizierung fällig wird, lässt sich an der Bezeichnung „Coding Agent“ nicht ablesen. Zu bewerten sind der Prozessschritt, in dem das Werkzeug arbeitet, die Wirkung einer möglichen Fehlfunktion und die Maßnahmen, mit denen das Team sie erkennt. Qualifizierungsartefakte für eine bestehende Werkzeugkette senken den Aufwand, decken einen zusätzlich eingesetzten Agenten aber nicht automatisch ab. Im ASPICE-Assessment kommt der Einsatz über die betroffenen Arbeitsergebnisse, die Werkzeugsteuerung, das Konfigurationsmanagement und die Qualitätsnachweise zur Sprache.

Automotive SPICE bewertet den Prozess, ISO 26262 die funktionale Sicherheit

Für ein Team, das Steuergerätesoftware für ein softwaredefiniertes Fahrzeug liefert, laufen zwei Nachweislogiken nebeneinander. Automotive SPICE bewertet die Prozessfähigkeit im Kundenprojekt. Das PAM 4.0 ist beim VDA QMC öffentlich zugänglich. ISO 26262 stellt Anforderungen an die funktionale Sicherheit des Produkts. Das Vertrauen in Softwarewerkzeuge behandelt Teil 8, Abschnitt 11. Den weiteren Rahmen behandelt der Compliance-Strang des Coding-Agents-Leitfadens.

Daneben stehen ISO/SAE 21434, ISO/PAS 8800:2024 und die KI-Verordnung. Sie beantworten andere Fragen. ISO/PAS 8800 behandelt KI als Bestandteil sicherheitsbezogener E/E-Systeme im Fahrzeug. Abschnitt 1 zum Geltungsbereich enthält keine spezifischen Leitlinien für Softwarewerkzeuge, die KI-Methoden verwenden. Die Werkzeugfrage bleibt deshalb im Rahmen dieses Artikels bei ISO 26262-8.

ISO/SAE 21434 betrifft die Cybersecurity-Entwicklung

ISO/SAE 21434 strukturiert die Cybersecurity-Entwicklung über den Fahrzeuglebenszyklus. Dieser Artikel konzentriert sich auf funktionale Sicherheit und Werkzeugvertrauen. Lieferketten- und Dokumentationspflichten nach NIS 2 sowie die rollenbezogene Einordnung nach der KI-Verordnung behandeln die Beiträge zu den NIS-2-Dokumentationspflichten für Entwicklerteams und zur KI-Verordnung.

Das ASIL bestimmt die Nachweistiefe, das TCL entsteht aus anderen Größen

ASIL und TCL beantworten verschiedene Fragen. Das ASIL, die Einstufung von A bis D, sagt, wie tief der Sicherheitsnachweis für die betrachtete Funktion reicht. Das Tool Confidence Level entsteht dagegen aus Tool Impact und Tool Error Detection. Die TCL-Bestimmung nach 11.4.5.4 kennt nur diese beiden Eingangsgrößen, und Tabelle 3 hat keine ASIL-Achse. Erst bei der Wahl der Qualifizierungsmethoden kommt das ASIL ins Spiel: Nach 11.4.4.1 f) richten sich die Methoden, mit denen ein Werkzeug qualifiziert wird, sofern eine Qualifizierung überhaupt nötig ist, nach dem ermittelten Tool Confidence Level und dem ASIL. Ein hohes ASIL macht aus einem unkritischen Werkzeug also kein qualifizierungspflichtiges.

Für die Werkzeugqualifizierung zählt der konkrete Einsatz, nicht das Etikett „Coding Agent“

Die folgende Einordnung folgt ISO 26262-8:2018, Abschnitt 11. Mit Stand 18. August 2026 ist das die veröffentlichte Ausgabe. Eine dritte Ausgabe ist bei ISO in Arbeit, aber noch nicht normativ.

Die Grundanforderung steht in 11.4.1 und knüpft an zwei Bedingungen, die zusammentreffen müssen. Eine von der Norm geforderte Aktivität stützt sich auf die korrekte Funktion des Werkzeugs, und die relevanten Ausgaben dieses Werkzeugs werden für den betreffenden Prozessschritt nicht geprüft oder verifiziert. Treffen beide Bedingungen zu, muss das Werkzeug die Anforderungen des Abschnitts 11 erfüllen.

Die Rechtsfolge ist dabei genauer, als sie oft wiedergegeben wird. Anwendbar wird zunächst der ganze Abschnitt 11, also die Beschreibung des Verwendungszwecks und die Einstufung über TI und TD. Eine Qualifizierungspflicht folgt daraus noch nicht: Nach 11.4.6.1 braucht ein Werkzeug mit TCL1 keine Qualifizierungsmethoden. Die Einstufung selbst entfällt damit nicht, sie mündet in den Software tool criteria evaluation report nach 11.5.1.

Tool Impact beschreibt nach 11.4.5.2 a) die Möglichkeit, dass eine Fehlfunktion des Werkzeugs Fehler in ein in Entwicklung befindliches sicherheitsbezogenes Item oder Element einbringt oder vorhandene Fehler unentdeckt lässt. TI1 ist zu wählen, wenn sich begründen lässt, dass diese Möglichkeit nicht besteht, in allen übrigen Fällen gilt TI2. Die Frage zielt also auf den Sicherheitsbezug, nicht auf eine Abstufung nach ASIL.

Die zweite Achse, Tool Error Detection nach 11.4.5.2 b), misst das Vertrauen in Maßnahmen, die eine Fehlfunktion des Werkzeugs und die daraus folgende fehlerhafte Ausgabe verhindern oder erkennen. TD1 steht für einen hohen, TD2 für einen mittleren Vertrauensgrad, TD3 ist die Auffangstufe für alle übrigen Fälle. Tabelle 3 verknüpft beide Achsen: TI1 ergibt unabhängig vom TD immer TCL1, ebenso jede Kombination mit TD1. TI2 mit TD2 ergibt TCL2, TI2 mit TD3 ergibt TCL3. Dieselbe Matrix beschreiben Siemens EDA, itemis, heicon und BTC Embedded.

Bei unklarer Einstufung sollen TI und TD nach 11.4.5.3 konservativ angesetzt werden, formuliert als Empfehlung, nicht als Pflicht.

Eine verbreitete Wiedergabe der zurückgezogenen Ausgabe 2011, etwa im Werkzeugqualifizierungsplan von Verifysoft und Validas, sperrt TD2 für den Fall, dass ein Werkzeug eine geforderte Tätigkeit ersetzt. In der Ausgabe 2018 steht diese Sonderregel nicht. Dort greift stattdessen die Auffangregel in 11.4.5.2 b), nach der TD3 immer dann zu wählen ist, wenn sich weder ein hohes noch ein mittleres Vertrauen in die Maßnahmen zur Verhinderung oder Erkennung einer Fehlfunktion und ihrer fehlerhaften Ausgabe begründen lässt. TD2 bleibt also offen, sobald ein mittleres Vertrauen begründbar ist.

Für einen codegenerierenden Agenten liefert das zugehörige Beispiel die naheliegendste Analogie. Es unterscheidet einen Codegenerator danach, ob der erzeugte Quellcode nach ISO 26262 verifiziert wird, und nennt bei verifiziertem Quellcode TD1, bei nicht verifiziertem TD3. Die Norm beschreibt an dieser Stelle ausdrücklich einen Codegenerator und nicht einen LLM-basierten Coding Agent. Für dessen Einstufung bleibt die Übertragung auf den konkreten Einsatz eigens zu begründen. Wird die Ausgabe nicht verifiziert, führt TD3 zusammen mit TI2 über Tabelle 3 zu TCL3.

Für TCL3 und TCL2 führen die Tabellen 4 und 5 vier Methoden auf, von der Nutzungserfahrung bis zur Entwicklung nach einer Sicherheitsnorm. Der Empfehlungsgrad je Methode hängt vom ASIL ab. Da es sich um alternative Einträge handelt, greift die Auslegungsregel aus Klausel 4.3: Anzuwenden ist eine Methodenkombination, die dem angegebenen ASIL angemessen ist, und zwar unabhängig davon, ob die Methoden in der Tabelle stehen oder nicht. Sind Methoden mit unterschiedlichem Empfehlungsgrad gelistet, sollten die höher empfohlenen bevorzugt werden. Für die gewählte Kombination, und ebenso für eine einzeln gewählte Methode, ist zu begründen, dass sie die zugehörige Anforderung erfüllt. Die Tabelle ersetzt deshalb keine projektbezogene Argumentation.

Die projektbezogene Verantwortung bleibt beim Anwender. Roberto Bagnara formuliert in seinen Workshopfolien, dass Auswahl und Qualifizierung des Werkzeugs beim Werkzeuganwender liegen. Anbieterzertifikate und Qualifizierungsartefakte können die Begründung unterstützen, ersetzen sie aber nicht.

Für Coding Agents fand sich in den geprüften öffentlich zugänglichen Quellen bis zum 17. August 2026 keine dokumentierte Anwendung dieser Mechanik durch ein Normungsgremium, einen OEM, einen Tier-1 oder eine Zertifizierungsstelle. Der Zulieferer kann sich deshalb nicht auf einen veröffentlichten Referenzfall stützen.

Offen bleibt außerdem, worauf sich die Einstufung eines nichtdeterministischen Werkzeugs bezieht: auf die Modellversion, die Konfiguration oder einen einzelnen Lauf. Auch dazu geben die geprüften Quellen keine belastbare Antwort.

Vorqualifizierte Werkzeugketten senken den Aufwand, decken den Agenten aber nicht automatisch ab

Die Ausgangsthese dieser Recherche lautete: Seriencode ist teuer, das Umfeld frei. Testfälle, Harness-Code und Werkzeugskripte schienen deshalb günstige Einsatzorte. Die Quellen verschieben diese Grenze: Auch Verifikationswerkzeuge können als TI2 eingestuft werden, und eigene Skripte können Teil der nachweispflichtigen Werkzeugkette werden.

LDRA, BTC Embedded und Siemens EDA stufen die jeweils betrachteten Verifikationswerkzeuge als TI2 ein. Aus diesen Herstellerbeispielen lässt sich nicht ableiten, dass jedes Testwerkzeug TI2 ist. Sie zeigen aber denselben Risikomechanismus: Ein Verifikationswerkzeug kann vorhandene Fehler übersehen.

Bei TI2 führt TD2 zu TCL2 und TD3 zu TCL3. Beide Fälle verlangen Qualifizierungsmaßnahmen. Wie hoch der Aufwand ausfällt, hängt von der projektbezogenen Einstufung und den verfügbaren Artefakten ab.

Mindestens sechs Hersteller bieten Qualifizierungsartefakte für Testwerkzeuge an oder pflegen sie: Razorcat, Vector, LDRA, MathWorks, dSPACE und BTC. Laut Safety Manual sind der dort beschriebene Kern-Workflow von TESSY sowie der Release- und Testprozess nach ISO 26262-8:2018 zertifiziert. Weitere Funktionen, darunter Bearbeitungs-, Umgebungs- und Schnittstellenfunktionen, liegen außerhalb dieses Zertifizierungsumfangs. Das belegt weder die Einstufung jedes Testwerkzeugs noch die Qualifizierung sämtlicher Produktfunktionen. Es zeigt aber, dass Hersteller abgegrenzte Workflows mit Qualifizierungsartefakten unterstützen.

Der Hersteller liefert damit vorbereitete Qualifizierungsartefakte. Vector hält auf der eigenen Produktseite fest, der Anwender könne die Dokumentation nutzen, „when performing the final project-specific classification and qualification of the tools within the context of your particular development processes“, denn „A final classification can only be made in the context of a specific product development process.“ Die projektspezifische Einstufung bleibt trotzdem beim Anwender.

Für Testinfrastruktur ist eine zweite Frage getrennt zu prüfen. Die Codierrichtlinienpflicht in ISO 26262-6:2018 hängt an 5.4.1 a), also an der sicherheitsbezogenen eingebetteten Software des Items. Eine ausdrückliche Aussage zu Testcode enthält die Ausgabe 2018 nicht, weder einschließend noch ausschließend: Begriffe wie test code, test harness oder production code kommen im Normtext nicht vor. Die belastbare Abgrenzung läuft deshalb nicht über die Kategorie Testcode, sondern über 9.4.1, wonach die Anforderungen greifen, wenn die Softwareeinheit ein sicherheitsbezogenes Element ist. Für die Werkzeuge verweist Teil 6 in 5.3.2 und in 5.4.1 NOTE 2 auf ISO 26262-8, Abschnitt 11, und führt qualifizierte Werkzeuge und Codierrichtlinien dort als getrennte Punkte.

Entscheidend ist daher der konkrete Einsatz. Wird ein Agent als Vorschlagswerkzeug genutzt und seine Ausgabe im vorgesehenen Prozessschritt nach einem festgelegten und dokumentierten Verfahren geprüft, kann die Einstufung anders ausfallen als bei einem Skript, Harness-Generator oder CI-Gate, dessen Ergebnis ungeprüft weiterwirkt. Ein Qualifizierungskit für die bestehende Testumgebung deckt den zusätzlich eingesetzten Agenten nicht automatisch ab. Auch für ihn bleibt eine projektbezogene TI/TD-Bewertung nötig.

Der wirtschaftliche Hebel liegt vor der Qualifizierung. Slotosch und Kollegen analysierten bei Validas und Infineon eine reale Werkzeugkette aus 37 Werkzeugen und 136 Anwendungsfällen. Elf lagen zunächst bei TCL2 oder TCL3. Nachdem sie kostengünstige Gegenmaßnahmen wie die Logfile-Inspektion ergriffen hatten, galt: „the TCL for 10 tools could be brought to TCL1, only one tool remained at TCL2.“ Für zehn Werkzeuge entfiel die Qualifizierungspflicht, ohne dass auch nur eines davon qualifiziert wurde.

Der gemessene Aufwand dafür lag „between 0,5 and 5 days (2 days average) per tool“. Zwei Vorbehalte gehören dazu: Die Arbeit stammt aus dem Jahr 2012 und bezieht sich auf die Ausgabe von 2011, und sie misst die Klassifizierung, nicht die Qualifizierung. In den geprüften öffentlichen Quellen fanden sich keine belastbaren, allgemein übertragbaren Kostenzahlen für eine vollständige Qualifizierung.

Trace-Links kann ein Agent vorschlagen, die semantische Konsistenz verlangt ASPICE zusätzlich

Damit verlagert sich die Frage von ISO 26262 zurück zum Prozessmodell. Automotive SPICE 4.0 hat Verfolgbarkeit und Konsistenz in eine einzige Basispraktik je Prozess zusammengezogen, wörtlich betitelt „Ensure consistency and establish bidirectional traceability“. Im PAM 4.0 ist das SWE.1.BP5, SWE.2.BP4, SWE.3.BP4, SWE.4.BP4, SWE.5.BP6 und SWE.6.BP4. Wer noch mit den Nummern aus 3.1 arbeitet, sucht an der falschen Stelle, dort waren es je zwei getrennte Praktiken.

Beide Begriffe definiert das PAM getrennt: „Traceability refers to the existence of meaningful references or links between work products. Consistency on the other hand addresses content and semantics.“ Der Link stellt die technische Verknüpfung her. Die Konsistenz betrifft die inhaltliche Aussage.

Unter nahezu jeder SWE-Basispraktik wiederholt das PAM denselben Vorbehalt: „Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.“ Ein automatisch erzeugter Link erfüllt die Basispraktik daher nicht allein. Inhalt und Semantik müssen ebenfalls geprüft werden.

Wie gut Sprachmodelle Links finden, wurde gemessen. Alor, Khatoonabadi und Shihab von der Concordia University berichten in „Evaluating the Use of LLMs for Documentation to Code Traceability“ vom 19. Juni 2025 von einer Präzision von 87 bis 100 Prozent bei einem Recall von 47 bis 75 Prozent. Der beste F1-Wert liegt bei rund 80 Prozent.

Für die Vollständigkeit des Nachweises ist der Recall besonders kritisch. Ein falscher Vorschlag kostet Prüfzeit. Ein nicht vorgeschlagener Link fehlt in der Traceability-Matrix. Bei 47 bis 75 Prozent Recall lässt ein rein maschineller Durchlauf ein Viertel bis gut die Hälfte der echten Verbindungen aus. Die Autoren beschreiben die Modelle deshalb als Assistenz für die Linksuche und empfehlen einen Human-in-the-loop-Ansatz.

Wie diese Arbeitsteilung praktisch aussehen kann, zeigt ein Marktbeispiel. Vector hat am 19. März 2026 VectorCAST 2026 mit der Funktion Reqs2x freigegeben. Laut Anbieter sind die erzeugten Zuordnungen und Testfälle für eine Prüfung durch den Anwender vorgesehen.

Die Quellen stützen den Agenten damit als Such- und Vorschlagswerkzeug für Trace-Links, nicht als alleinige Instanz für den Nachweis. Jeder vorgeschlagene Link muss inhaltlich geprüft werden. Zusätzlich ist zu prüfen, ob die Traceability-Matrix vollständig ist. Arbeitet der Agent aus einer strukturierten Spezifikation, bleibt zudem nachvollziehbar, aus welchem Arbeitsergebnis ein Link abgeleitet wurde.

AUTOSAR Classic und Adaptive im Vergleich: Wo ein Agent sinnvoll ansetzen kann

Wo ein Agent im Steuergerät sinnvoll ansetzen kann, hängt auch von der Plattform ab. AUTOSAR liegt in den Ausprägungen Classic und Adaptive vor. Beide werden hier auf Basis des Release R25-11 betrachtet. Für den Agenteneinsatz ist vor allem relevant, wie viel Anwendungslogik generiert und wie viel von Hand implementiert wird.

In Classic gibt die Spezifikation den Codierstandard normativ vor. AUTOSAR_CP_SWS_BSWGeneral R25-11 §7.1.1, Anforderung [SWS_BSW_00115]: „If the BSW Module implementation is written in C language, then it shall conform to the MISRA C 2012 Standard“. Verwiesen wird auf die Ausgabe von 2012, zwei Ausgaben hinter dem aktuellen MISRA C:2025 vom März 2025.

In Classic entsteht ein erheblicher Teil der Infrastruktur aus Konfiguration und Codegenerierung. Die RTE wird aus der ARXML-Konfiguration erzeugt. Handgeschriebene Logik bleibt unter anderem in den Runnable-Rümpfen der Softwarekomponenten und in Complex Device Drivers. Wie groß dieser Anteil ist, hängt von der Architektur ab.

Bei AUTOSAR Adaptive wird mehr Anwendungslogik von Hand in den Serviceimplementierungen geschrieben. Anwendungen verwenden das PSE51-Profil des POSIX-Standards. Dynamische Speicherverwaltung spielt laut Plattformbeschreibung eine zentrale Rolle. Eine verbindliche C++-Version schreiben die R25-11-Dokumente nicht vor. Die verbreitete Gleichsetzung von Adaptive mit C++14 stammt aus einem nicht mehr aktuellen Richtliniendokument.

Eine dafür relevante Stelle steht in AUTOSAR_AP_EXP_PlatformDesign R25-11, §8.4. Der Generator liefert typsichere C++-Klassen für Felder, Events und Methoden. Die Service Provider Skeletons bleiben abstrakte Basisklassen. Die konkrete Serviceimplementierung wird ergänzt. Dort ist Agentenunterstützung technisch plausibel, unterliegt aber denselben Prüf- und Nachweisanforderungen wie anderer Code.

Die Studienlage deckt das praktische Einsatzfeld damit nur teilweise ab. Die verfügbaren Messungen zum Konformitätsverhalten betreffen vor allem MISRA C und damit das Classic-Umfeld. Für Adaptive, wo mehr Serviceimplementierung von Hand entsteht, ist die öffentlich zugängliche Beleglage dünner.

Ein mögliches Einsatzfeld ist die Migration von Classic nach Adaptive. Auch dort müssen agentengestützte Codeänderungen denselben projektbezogenen Reviews und Verifikationsschritten standhalten wie andere Beiträge.

MISRA-Analyse findet Regelverstöße, beweist aber nicht die richtige Funktion

Für die Codierrichtlinien unterscheidet ISO 26262-6:2018 nicht nach der Herkunft des Codes. Beispiel 1 zu 5.4.3 nennt MISRA C als Codierrichtlinie für die Sprache C, die ausdrücklich auch Hinweise für automatisch erzeugten Code enthält, und die Anmerkung zu 8.4.5 hält fest, dass MISRA C viele der dort geforderten Entwurfsprinzipien auf Quellcodeebene abdeckt. Agentenerzeugter Produktivcode fällt damit unter dieselbe Richtlinienpflicht wie handgeschriebener. Wo statische Analyse in die CI eingebunden ist, prüft sie beides nach denselben Regeln. Sie findet Regelverstöße, belegt aber keine funktionale Richtigkeit: Code kann die Codierrichtlinien einhalten und trotzdem das falsche Register beschreiben.

Die vorhandenen Studien zeigen Regelverstöße, aber keine belastbare Konformitätsquote

Ein nicht begutachteter technischer Bericht der Middle East Technical University untersuchte sechs Modelle an zwei Embedded-C-Aufgaben mit je drei Läufen. Kein Modell erzeugte in diesem Versuchsaufbau vollständig MISRA-C:2012-konformen Code, obwohl der Prompt „100% compliant“ verlangte. Rule 15.5 wurde allein im COBS-Datensatz 68-mal verletzt (METU/II-TR-2026, Januar 2026). Das ist ein negativer Befund für dieses kleine Experiment, keine allgemeine Konformitätsquote.

Der Report vermutet einen strukturellen Grund: Öffentlicher C-Code folgt häufig Mustern, die nicht auf MISRA-Konformität optimiert sind. Das verbreitete Early-Return-Muster kann etwa gegen Rule 15.5 verstoßen, wenn eine Funktion dadurch mehr als einen Rücksprungpunkt erhält. Das Modell folgt dann eher häufigen Trainingsmustern als der Nischenanforderung im Prompt.

Zudem erzeugte das Modell mit den wenigsten Regelbefunden im selben Versuchsaufbau am häufigsten fehlerhaften Code. Wenige MISRA-Meldungen belegen daher weder Kompilierbarkeit noch funktionale Richtigkeit. Geprüft wurde MISRA C:2012, nicht die Ausgabe von 2025.

Ein größerer, ebenfalls nicht begutachteter Preprint von zwei Parasoft-Mitarbeitern zeichnet ein weniger negatives Bild. Er untersuchte vier Modelle an 26 C++-Aufgaben mit MISRA C++:2023. Von 2.080 Baseline-Versuchen kompilierten 1.665, also 80,05 Prozent. Unter 27.762 Befunden entfielen 42,92 Prozent auf Required- und 57,08 Prozent auf Advisory-Regeln. Die einzige Meldung der Kategorie Mandatory erwies sich als Fehlalarm. Das relativiert die Zuspitzung auf Mandatory-Regeln, belegt aber keine Konformität: Rund ein Fünftel der Ausgaben wurde nicht statisch analysiert, und die kompilierenden Ausgaben enthielten zahlreiche Required-Verstöße.

MISRA AC INT:2025 behandelt LLM-basierte Werkzeuge nicht ausdrücklich. Die dort beschriebene Erleichterung für klassische automatische Codegenerierung setzt einen deterministischen Generator und Back-to-back-Tests gegen ein verifiziertes Modell voraus. Die geprüften Quellen belegen nicht, dass sich diese Voraussetzungen auf einen nichtdeterministischen Agenten übertragen lassen.

Die Herkunft des Codes ersetzt keine projektbezogene Werkzeugeinstufung

Ob der analysierte Code von einem Menschen oder einem Agenten stammt, ist für die TI/TD-Bewertung des Analysewerkzeugs nicht das alleinige Kriterium. Maßgeblich bleiben der konkrete Einsatz und die vorgesehenen Erkennungsmaßnahmen. Die Herkunft des Codes kann jedoch die Menge und Art der Befunde verändern.

Die geprüften Studien erlauben keine belastbare Aussage darüber, ob die Auswertung der Befunde bei agentengeneriertem Code mehr Aufwand verursacht als bei menschlich geschriebenem Code. Es fehlt eine entsprechende Vergleichsgruppe.

Wo ein Coding Agent im ASPICE-Assessment sichtbar wird

Im hier betrachteten Zuliefererkontext wird der Nachweis gegenüber dem Auftraggeber geführt. Das unterscheidet ihn vom aufsichtsrechtlichen Kontext des BaFin/MaRisk-Beitrags. Für diesen Artikel zählt deshalb, welche Prozessnachweise und Arbeitsergebnisse im Kundenassessment geprüft werden.

Das PAM 4.0 enthält keine eigene Basispraktik zur ISO-26262-Werkzeugqualifizierung. Daraus folgt aber nicht, dass der Agent im Assessment unsichtbar bleibt. Sein Einsatz kann über die betroffenen SWE-Arbeitsergebnisse, die Werkzeugsteuerung, das Konfigurationsmanagement und die VDA-Guideline zu „AI assistance in development“ zur Sprache kommen.

Wo der Werkzeugeinsatz im Assessment auftaucht

Der Werkzeugeinsatz kann bereits auf PA1.1-Ebene sichtbar werden, wenn ein Agent Arbeitsergebnisse in SWE.1 bis SWE.6 erzeugt und der Assessor deren Umsetzung stichprobenartig prüft. Ab Capability Level 2 kommen die Generic Practices zur Ressourcensteuerung hinzu. GP 2.1.3 nennt Werkzeuge und Lizenzen als mögliche benötigte Ressourcen, GP 2.1.4 verlangt deren Bereitstellung. Auf Capability Level 3 konkretisiert GP 3.1.3 den Ressourcenbedarf für den Standardprozess. GP 3.2.3 verlangt, Verfügbarkeit und Nutzung der Ressourcen zu messen und zu überwachen. Das Konfigurationsmanagement muss außerdem die relevanten Werkzeuge abdecken.

Die ML-Prozesse in ASPICE 4.0 zielen auf das Modell im Fahrzeug

Die mit 4.0 eingeführten ML-Prozesse MLE.1 bis MLE.4 und SUP.11 betreffen nach Zielsetzung und Beispielen das ML-Modell als Produktbestandteil im Fahrzeug. Das PAM enthält keinen eigenen Prozess für generative Entwicklungsassistenten. Die Agentenfrage wird deshalb nicht über die MLE-Prozesse gelöst.

Welche ASPICE-Nachweise sich durch einen Agenteneinsatz verändern

Im seit März 2026 öffentlich zugänglichen Yellow Volume zur 3. überarbeiteten Auflage der VDA ASPICE Guidelines steht hierzu eine konkrete Empfehlung: §2.5.5 „AI assistance in development“. Der Abschnitt behandelt den Werkzeugeinsatz als Entscheidung auf der Umsetzungsebene und verlangt klare Kriterien für den Umgang mit den Risiken. Das Dokument ist nicht bindend und hat die im VDA-QMC-Webshop weiterhin geführte 2. überarbeitete Auflage von November 2023 noch nicht offiziell ersetzt.

Das Yellow Volume bezieht sich bereits auf Automotive SPICE PAM 4.1. Der VDA-QMC-Webshop führte zum 18. August 2026 dagegen weiterhin PAM 4.0 als aktuelle veröffentlichte Fassung. Die Hinweise aus §2.5.5 werden hier deshalb als nicht bindende Vorabempfehlung behandelt.

Die Basispraktiken in SWE.1 bis SWE.6 bleiben unverändert. Verändert werden die eingesetzten Werkzeuge, die Kontrollen und die Nachweise, mit denen das Team die Praktiken belegt. Die dokumentierte Prüfung wird damit zu einem wichtigen Nachweis, und die Frage, wer im Team den Agentencode prüft, gehört vorher entschieden.

Was ins ASPICE-Assessment mitgeht

Diese Sonderregeln stehen nicht im normativen PAM, sondern in den nicht bindenden VDA-Guidelines. Sie regeln, ob SWE.4.BP3 abgewertet wird, und setzen einen Nachweis voraus, dass der erzeugte Code korrekt und konsistent zum Modell ist. Auf einen Coding-Assistenten lassen sie sich nicht pauschal übertragen. Eine allgemeine Verringerung des Verifikationsaufwands folgt daraus nicht.

Zur Einordnung der Kennungen: PA1.1 steht für die Prozessdurchführung auf Capability Level 1, die Generic Practices GP 2.x gehören zu Level 2, die GP 3.x zu Level 3. GP 2.1.3 bestimmt die benötigten Ressourcen, GP 3.1.3 tut dasselbe für den Standardprozess. Beide nennen in ihren Anmerkungen Werkzeuge und Lizenzen als Beispiele. GP 2.1.4 verlangt, die Ressourcen bereitzustellen, GP 3.2.3 zusätzlich, ihre Verfügbarkeit und Nutzung zu messen und zu überwachen.

SUP.8 ist das Konfigurationsmanagement, SUP.1 die Qualitätssicherung, PA2.2 die Lenkung der Arbeitsergebnisse. SWE.3.BP3 behandelt den Softwaredetailentwurf und die Erstellung der Software-Units. MBD.RL.6 und MBD.RL.7 sind Sonderregeln der modellbasierten Entwicklung und setzen eine qualifizierte Werkzeugkette voraus.

Exkurs in den Maschinenbau: IEC 61131-3, was sich übertragen lässt und was nicht

Die Werkzeugfrage stellt sich in der Steuerungstechnik anders. Der offizielle Katalogeintrag zu IEC 61508-3:2010 bestätigt, dass der Standard auch Anforderungen an unterstützende Entwicklungs-, Konfigurations-, Test- und Debuggingwerkzeuge enthält. Da Abschnitt 7.4.4 nicht im Volltext geprüft wurde, wird die dortige Klassifizierung hier nicht im Detail wiedergegeben. Auf das TI/TD-Raster der ISO 26262 ließe sie sich ohnehin nicht pauschal übertragen.

Bei den Sprachen liegt IEC 61131-3 seit dem 22. Mai 2025 in Edition 4.0 vor. Die Edition umfasst Structured Text, Kontaktplan, Funktionsbausteinsprache und Ablaufsprache. Die Instruction List ist gestrichen. Für die grafischen Sprachen gibt es zumindest einen begrenzten negativen Befund: Zhang und de Sousa berichten, dass die Erzeugung von Kontaktplänen selbst in einfachen Fällen schwierig bleibt (arXiv 2410.15200). Daraus folgt keine allgemeine Aussage über den Trainingskorpus.

Anders liegt es beim Adressaten. Auch für die mechanische Entwicklung gibt es ein eigenes Prozessreferenz- und Prozessbewertungsmodell. intacs führt Mechanical SPICE v2.1 als Modell, das die domänenspezifische Erweiterung von Automotive SPICE 4.0 für die Mechanikentwicklung werden soll. Daraus folgt aber nicht, dass es in Kundenprojekten dieselbe Verbreitung oder vertragliche Bedeutung wie Automotive SPICE besitzt. Belege dafür fanden sich in den geprüften öffentlichen Quellen nicht. Die konkrete Assessmentanforderung bleibt deshalb vom jeweiligen Kunden- und Projektkontext abhängig. Übertragbar sind die Logik der Werkzeugkette und die projektbezogene Begründung, nicht das ASPICE-Assessment.

Organisationsgröße und Betriebsmodell sind davon getrennte Entscheidungen. Ob ein Modell im eigenen Rechenzentrum oder bei einem Anbieter läuft, betrifft Datenkontrolle und Betrieb, ändert aber nicht automatisch die projektbezogene Werkzeugeinstufung. Die Beiträge zur KI-Coding-Strategie für den Mittelstand und zum On-Premise-Betrieb von Coding Agents behandeln diese Fragen im Detail.

Diese Punkte helfen bei der Entscheidung, ob und wo ein Agent eingesetzt werden kann. Die Einführung selbst ist eine eigene Aufgabe, und was dafür zu tun ist, steht im Plan für die ersten 90 Tage.

Die Entscheidung hängt am konkreten Prüfpfad

Aus den geprüften Quellen folgt für Coding Agents in der Fahrzeugentwicklung weder eine pauschale Freigabe noch eine automatische Qualifizierungspflicht. Beide Antworten lassen die von ISO 26262-8 verlangte Einstufung aus und lassen sich im Kundenassessment entsprechend schwer begründen.

Diese Einstufung muss das Team für den eigenen Einsatz beschreiben: Welches Arbeitsergebnis erzeugt der Agent, an welcher Stelle im Prozess, welche Wirkung hätte eine Fehlfunktion dort, nach welchem festgelegten und dokumentierten Verfahren wird die Ausgabe geprüft oder verifiziert, und wer verantwortet die Freigabe. Genau diese dokumentierte Begründung kann das Team dem Assessor vorlegen.

Vorqualifizierte Werkzeugketten verringern den Aufwand, soweit ihr dokumentierter Umfang reicht. Was darüber hinausgeht, muss das eigene Projekt begründen.