Lokale KI für Embedded C und C++: Unit-Tests, MISRA-Befunde und Dokumentation offline

Unit-Tests und MISRA-Korrekturen mit lokalem LLM

Lokale KI für Embedded C ist ein offenes Codemodell auf einer Workstation in Ihrem Entwicklungsnetz. Es entwirft Unit-Tests aus Anforderungen und Quellcode, erklärt MISRA-Befunde, schlägt regelkonforme Korrekturen vor und dokumentiert Module, die seit Jahren niemand angefasst hat; der Code, der oft einem OEM-Kunden gehört und unter einer Geheimhaltungs­vereinbarung steht, bleibt dabei im Haus. Das ausführlichste veröffentlichte Ergebnis stammt von der TUM und Hydac Software: Mit einem Suchindex über Header, Quellen und alte Tests bestanden 84,5 Prozent der generierten Tests die Laufzeitprüfung, ohne ihn 50,5 Prozent. Eine Workstation mit einer NVIDIA RTX PRO 4500 Blackwell (32 GB) ist die kleinste Konfiguration, die wir einem kleinen Team empfehlen.

Dieser Leitfaden richtet sich an Software- und Testleitungen bei Automobilzulieferern, im Maschinenbau und bei Medizin­produkte­herstellern sowie an die IT, die deren Build-Infrastruktur betreibt. Unser Leitfaden zu lokaler KI für die SPS-Programmierung behandelt IEC-61131-3-Code auf Steuerungen; diese Seite behandelt C und C++ auf Mikrocontrollern und Embedded-Prozessoren. Für Unit- und End-to-End-Tests in Business-Software lesen Sie unseren Leitfaden zur Testgenerierung mit KI on-premise, für Review-Bots an Merge Requests den Leitfaden zum selbst gehosteten KI-Code-Review.

Was die Studie EmbC-Test gemessen hat

Das Paper EmbC-Test wurde am 10. März 2026 bei arXiv eingereicht, von Autoren der Technischen Universität München, unter anderem aus deren Munich Institute of Robotics and Machine Intelligence (MIRMI), und der Hydac Software GmbH. Es ist der ausführlichste öffentliche Test von Testgenerierung mit LLMs an industriellem Embedded-C-Code, den wir gefunden haben. Die Autoren bauten eine Pipeline mit Retrieval-Augmented Generation (RAG): einen Suchindex über C-Header, Quellcode und die vorhandenen Tests des Unternehmens, aus dem die fünf passendsten Abschnitte zusammen mit der Anforderung in den Prompt gehen. Die generierten Tests waren Python-basierte Tests für Embedded C, wie die bestehende Testsuite des Unternehmens, und mussten „compile and run against the target software“.

EmbC-Test, arXiv 2603.09497v1 vom 10. März 2026, Tabelle 1 und Text, gelesen am 30. Oktober 2026. Laufzeitgültig: Der generierte Test bestand die dreistufige Prüfung der Autoren aus Syntax, Kompilierung (Import) und Lauf. Messungen der Autoren am Code von Hydac; zwei unabhängige Fachleute bewerteten die Tests. Von den geprüften Tests wurden 38,9 Prozent unverändert übernommen, 55,6 Prozent brauchten Änderungen und 5,6 Prozent mussten neu geschrieben werden. Manuell entstand im selben Vergleich etwa ein Test pro Stunde.

Die Suche entscheidet mehr als alles andere: Die passenden Abschnitte hoben den Anteil lauffähiger Tests um 34 Punkte, zufällig gewählte nur um 12, nach unserer Rechnung aus der Tabelle. Die Abdeckung bleibt deutlich unter den handgeschriebenen Suiten, die laut den Autoren über Monate schrittweise verfeinert wurden, während die generierten Tests aus einem einzigen Lauf ohne Rückmeldung stammen. Auch das Review bleibt, denn mehr als die Hälfte der Tests brauchte Änderungen, bevor sie übernommen wurden. Auf dieser Grundlage schätzen die Autoren, dass der Testaufwand für eine Bibliothek mit 57 Softwareanforderungen von 57 Stunden auf 19,2 Stunden sinken könnte, eine Ersparnis von 66 Prozent.

Das Paper nennt auch Grenzen. Die Autoren schreiben, dass Zero-Shot-Generierung unzuverlässig ist und generierte Tests falsche Erwartungen festschreiben können, und dass der Ansatz am besten bei gut dokumentierten Codebasen mit einheitlicher Benennung und einem reichen Bestand an alten Tests funktioniert. Sie empfehlen ausdrücklich, dass ein Mensch jeden Entwurf prüft. Alle Ergebnisse stammen aus der Codebasis eines einzigen Unternehmens. Das Embedding-Modell ihrer Pipeline war „locally hosted“, und als Ausgangspunkt schlagen sie „a code-optimized embedding model“ vor; das erzeugende Modell war „a cloud-hosted LLM“, das das Paper nicht nennt. Einen veröffentlichten Vergleich offener Modelle für diese Aufgabe haben wir nicht gefunden, der lokale Weg muss also an Ihren eigenen Anforderungen gemessen werden.

Die Testschleife auf eigener Hardware

Der Ablauf behält jeden Schritt, den das Paper geprüft hat, und ergänzt die Rückmeldung, die die Autoren als künftige Arbeit nennen.

1. Projekt indexieren. Header, Quellen, vorhandene Tests und Ihre Codierrichtlinien kommen in einen Suchindex. Qwen3-Embedding-0.6B (Apache 2.0) ist ein kleines Embedding-Modell, dessen Modellkarte Code-Retrieval unter seinen Fähigkeiten nennt. Bauen Sie den Index nach jedem Merge neu auf, damit das Modell die aktuellen Schnittstellen sieht.
2. Aus einer Anforderung entwerfen. Jemand aus dem Team wählt eine Anforderung; das Modell erhält sie mit den fünf besten Abschnitten und entwirft einen Test in Ihrem Framework: im Python-Harness des Unternehmens wie bei Hydac oder in einem C-Framework wie Unity, das seine Autoren als „a unit-testing framework for C“ beschreiben, mit CMock (MIT) für Mocks und Stubs.
3. Bauen und ausführen. Ein Build-Rechner kompiliert den Test für den Host oder den Target-Simulator und führt ihn aus. Compilerfehler und fehlgeschlagene Assertions gehen für eine feste Zahl von Runden an das Modell zurück, danach wird der Entwurf verworfen und der Grund festgehalten.
4. Abdeckung messen. Ihr Coverage-Werkzeug zeigt, was die neuen Tests hinzufügen, die Größe, die EmbC-Test mit den manuellen Suiten verglich.
5. Prüfen. Eine Ingenieurin oder ein Ingenieur übernimmt, ändert oder verwirft jeden Test anhand der Anforderung und hält die Entscheidung fest; nach einem Monat kennen Sie Ihre eigene Übernahmequote.

Die GPU arbeitet nur, solange das Modell schreibt. Kompilieren und Ausführen kosten Zeit auf den Build-Rechnern, daher bedient eine Workstation mehr Personen, als ihre Zahl paralleler Sitzungen vermuten lässt.

Sie können die Workstation allein bestellen, die Einrichtung von Modell und Code-Index allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet. Die Anbindung an Ihre Build-Rechner, Ihr Test-Framework und Ihr Coverage-Werkzeug hängt von Ihrer Toolchain ab, deshalb vereinbaren wir sie in einem Pilotprojekt; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

MISRA-C-Befunde mit einem lokalen Modell erklären und beheben

MISRA C:2025 ist die aktuelle Ausgabe der Richtlinien; der Shop des MISRA-Konsortiums nennt sie „Updated in March 2025“ und schreibt, dass sie die Fassungen von 2023, 2019, 2012, 2004 und 1998 ersetzt. Ihr statischer Analysator findet die Verstöße. Ein lokales Modell übernimmt den Teil, der Ingenieurszeit kostet: Es liest die Funktion um einen Befund, erklärt in einfachen Worten, warum die Regel greift, schlägt eine regelkonforme Korrektur des Codes vor oder entwirft, wo der Code bleiben muss, die Begründung für eine Abweichung, die eine Ingenieurin oder ein Ingenieur vervollständigt. Danach läuft der Analysator erneut über den geänderten Code, und die Unit-Tests laufen erneut, um zu zeigen, dass sich das Verhalten nicht geändert hat. Das Modell erklärt einen Befund nie für erledigt; das tut nur der nächste saubere Lauf des Checkers.

Der quelloffene Analysator Cppcheck (GPL-3.0) bringt ein MISRA-Add-on mit, das laut Handbuch (gelesen am 31. Oktober 2026) „is used to verify compliance with MISRA C 2012“; dasselbe Handbuch sagt: „Misra checkers in open source Cppcheck only cover MISRA rules partially“, und verweist für vollständige Abdeckung auf Cppcheck Premium. Teams, die MISRA C:2025 vollständig prüfen müssen, behalten daher den kommerziellen Checker, den ihr Prozess qualifiziert hat. Auch die Regeltexte verlangen Sorgfalt. Das Cppcheck-Handbuch hält fest, dass sein Skript „does not provide rule texts, those should be downloaded from MISRA“, und MISRA verkauft seine Dokumente als „single user licenses for the named individuals“, die „may not be shared or transferred“. Bevor jemand den vollständigen Richtlinientext in einen gemeinsamen Suchindex legt, prüfen Sie, was Ihre Lizenz erlaubt; eine kurze Notiz je Regel in den Worten Ihres Teams, mit der Regelnummer, gibt dem Modell, was es braucht.

VectorCAST Reqs2x und lokale Modelle

Auch die Hersteller von Testwerkzeugen bauen diese Funktion ein. Vectors VectorCAST 2026 enthält Reqs2x, das Vector als „AI-powered Requirements-Based Test Creator“ bezeichnet. Laut Vectors Produktseite, gelesen am 31. Oktober 2026, ordnet es mit Program Slicing und LLMs Anforderungen aus DOORS, Polarion oder CSV-Dateien den Funktionen zu, die sie umsetzen, erzeugt Testfälle mit Rückverweis auf die Anforderungen und legt beides zur Prüfung vor: „Nothing is accepted automatically.“ Die Seite beschreibt einen Ansatz „Bring Your Own Model“ und sagt: „On-premises, cloud, and hybrid deployments are all supported“, ohne Modelle oder Schnittstellen zu nennen. Für VectorCAST-Kunden kann ein Modellserver auf Ihrer eigenen GPU also das On-Premises-Modell sein; fragen Sie Vector, welche Schnittstelle die Modelloption erwartet, bevor Sie die Hardware planen. Laut der Seite wurde die Funktion mit Blick auf MISRA C:2025 und die Anforderungen des EU AI Act entworfen; ISO 26262 oder Werkzeugqualifizierung erwähnt sie nicht.

Warum das Modell außerhalb der Nachweise nach ISO 26262 bleibt

Generierte Tests werden nur über Ihren Prozess zum Sicherheitsnachweis. ISO 26262-8:2018, Abschnitt 11, behandelt das Vertrauen in den Einsatz von Softwarewerkzeugen. Er leitet die Vertrauensstufe eines Werkzeugs aus dem Tool Impact ab, also ob ein Werkzeugfehler einen Fehler ins Produkt bringen oder übersehen kann, und aus der Tool Error Detection, also wie wahrscheinlich ein solcher Fehler erkannt wird, und verlangt auf den höheren Vertrauensstufen eine Werkzeugqualifizierung.

Wir empfehlen einen Aufbau, in dem das Modell nur entwirft. Eine Ingenieurin oder ein Ingenieur prüft jeden Test gegen die Anforderung, Ihr qualifiziertes Testwerkzeug führt ihn aus und Ihr qualifiziertes Coverage-Werkzeug misst ihn; der Nachweis ist dann ein geprüfter Test mit protokolliertem Lauf, genau wie bei einem handgeschriebenen Test. Wie Ihr Safety Case das Modell als Werkzeug einstuft, entscheiden Ihr Functional-Safety-Manager und Ihr Assessor. Für Software in Medizinprodukten wendet Ihre Abteilung für Regulatory Affairs die eigenen Regeln für Werkzeuge und Nachweise an; unser Leitfaden für Medizin­produkte­hersteller behandelt die regulatorischen Unterlagen, unser Leitfaden für Automobilzulieferer die Qualitätsdokumente rund um den Code.

Welche Workstation oder welcher Server für die Testgenerierung

Wir dimensionieren nach unserer Regel für Nutzer je Karte, wie in unserem Leitfaden, wie viele Nutzer eine RTX PRO 6000 bedient: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB pro Karte und abzüglich der Gewichte. Es bleiben 25,7 GiB auf einer 32-GB-Karte, 61,5 GiB auf der RTX PRO 5000 72 GB und 83,0 GiB auf einer RTX PRO 6000 mit 96 GB. Eine Sitzung mit 32.768 Token fasst die Anforderung, die gefundenen Abschnitte, die zu testende Einheit und die Compilerausgabe. Jede Zeile enthält Qwen3-Embedding-0.6B für den Index.

Unsere Schätzungen nach der Regel für Nutzer je Karte, keine Messungen: Sitzungen, die in den Speicher passen; wie schnell jede läuft, hängt von der Bandbreite der Karte ab. Gewichte: gpt-oss-20b 13,76 GB, Qwen3-Coder-30B-A3B 31,2 GB in FP8, Qwen3-Coder-Next 80,4 GB in FP8, Qwen3-Embedding-0.6B 1,19 GB (Dateilisten auf Hugging Face). 16-Bit-Cache je 32K-Sitzung: 0,75 GiB (gpt-oss-20b), 3 GiB (Coder-30B-A3B, FP8-Cache in Klammern), 0,75 GiB plus fester Zustand (Coder-Next, ohne Embedding-Modell 110 Sitzungen wie in unserem SPS-Leitfaden).

Einstieg, eine RTX PRO 4500. Die RTX PRO 4500 Blackwell hat 32 GB GDDR7, 896 GB/s und 200 W. Sie hält gpt-oss-20b (21 Mrd. Parameter, 3,6 Mrd. aktiv, Apache 2.0) mit dem Embedding-Modell und 15 Sitzungen. Qwen3-Coder-30B-A3B, ein Codemodell mit 30,5 Mrd. Parametern, 3,3 Mrd. aktiv und Tool Calling, passt in Ollamas 4-Bit-Fassung mit 19 GB, lässt aber nur Platz für zwei Sitzungen. Die RTX PRO 4000 mit 24 GB behält nach unserer Regel 18,5 GiB, genug für gpt-oss-20b mit 6 solchen Sitzungen; unsere Seite zu 30B-Modellen auf 24-GB-Karten behandelt diese Klasse. Eine Workstation mit einer RTX PRO 4500 nimmt nach unserer Schätzung etwa 0,6 kW an der Steckdose auf (die Karte, ein Prozessor der 350-W-Klasse und 15 Prozent für den Rest), und unsere Seite zum Kauf einer RTX-PRO-4500-Workstation listet die Ausführungen.

Einstieg für ein Team, eine RTX PRO 5000 72 GB. Qwen3-Coder-30B-A3B läuft hier in FP8, also mit 8-Bit-Gewichten statt der 4 Bit auf der RTX PRO 4500, und hält 10 Sitzungen, mit FP8-Cache 20, bei etwa 0,75 kW nach unserer Schätzung.

Mitte, eine RTX PRO 6000. Die Workstation Edition (600 W) oder Max-Q (300 W) mit 96 GB hält dasselbe Modell mit 17 Sitzungen oder, für Teams, die ein größeres Modell wollen, gpt-oss-120b mit 18 Sitzungen zu 32K nach unserer Regel; eine Workstation Edition nimmt nach unserer Schätzung etwa 1,1 kW auf. Zwei Karten der Workstation Edition sind für diese Edition das realistische Maximum, drei oder vier Max-Q gehören nur in ein dafür gebautes Gehäuse mit starkem, gerichtetem Luftstrom.

Groß, ein Server mit zwei Karten. Der Einstiegsserver auf unserer Seite zu KI-Servern trägt zwei RTX PRO 6000 Server Edition, zwei AMD-EPYC-Prozessoren und 384 GB DDR5-ECC-Speicher und nimmt nach unserer Schätzung etwa 1,8 kW auf. Als Paar halten die Karten Qwen3-Coder-Next (80 Mrd., 3 Mrd. aktiv, Apache 2.0) für mehrere Teams am Tag und entwerfen nachts Tests für eine ganze Modulbibliothek.

Eine veröffentlichte Geschwindigkeit dieser Modelle bei der Testgenerierung für Embedded-Code gibt es nicht. Das Tempo hängt von der Speicherbandbreite der Karte, den aktiven Parametern des Modells und der Länge des Prompts ab; messen Sie daher eine Stichprobe Ihrer eigenen Anforderungen, bevor Sie Durchlaufzeiten zusagen.

Wir bauen diese Workstations und Server auf Bestellung; senden Sie uns Ihre Toolchain, ein Beispielmodul mit seinen Anforderungen und die Größe Ihres Teams, und unser Team antwortet mit einer Konfiguration.

Offline einrichten, für die IT

1. Ohne Internetzugang installieren. Treiber, Container-Runtime, Modellserver und Gewichte kommen über einen Staging-Rechner auf die Maschine, wie unser Leitfaden zum Air-Gapped-LLM-Server beschreibt. Die Maschine braucht dann keine Internetverbindung, und Kundencode unter NDA bleibt in Ihrem Netz.
2. Modelle bereitstellen. Für ein Pilotprojekt auf einer Workstation genügt Ollama; vLLM bedient ein Team effizienter. vLLMs --api-key schützt nur einen Teil der Pfade, setzen Sie daher ein LLM-Gateway mit Schlüsseln und Abfrageprotokoll davor.
3. Build-Rechner anbinden. Geben Sie dem Assistenten ein Werkzeug, das eine einzelne Testdatei mit Ihrem Cross-Compiler oder Simulator baut und ausführt und die Ausgabe zurückgibt. Ohne dieses Werkzeug wartet jeder Entwurf darauf, dass jemand ihn von Hand kompiliert.
4. Über Protokolle entscheiden. Prompts enthalten Kundencode. Legen Sie vor dem ersten Lauf fest, wie lange das Gateway sie aufbewahrt und wer sie lesen darf; unser Artikel zu Geschäftsgeheimnissen, NDAs und KI-Werkzeugen behandelt die vertragliche Seite, unser Leitfaden zur Richtlinie für KI-Coding-Assistenten die internen Regeln.
5. Messen. Nehmen Sie 20 Anforderungen mit geprüften Tests aus einem abgeschlossenen Projekt und wiederholen Sie sie nach jedem Modell- oder Prompt-Wechsel; zählen Sie lauffähige Tests, Abdeckung und den Anteil, der ohne Änderung übernommen wird, die Messgrößen von EmbC-Test.

FAQ